Schema details page: embed Swagger-UI

[ronytw]

Expected behaviour

In the Schema details page, we'd like to see the content rendered in a dedicated swagger-ui section. The OAS3 specification to be rendered comes from the downloadUrl of the distribution associated with the Schema.

Current behaviour

No swagger-ui component is embedded. This is an enhancement.

Proposed solution

• The swagger-ui component is already in use with the api-docs page.
• The details of a schema, returned by the backend for the frontend to render the details page, already include a distribution, which is a list (!!!) of strings. They represent the accessUrl of the distribution. The downloadUrl might be exposed as per Index and expose downloadUrl for distribution of schemas. dati-semantic-backend#34.

Context

For who has access to the "NDC_mvp" Zeplin project, this is the link to the mock-up.

[ronytw]

We're encountering an issue with CORS: the Swagger-UI component is meant to retrieve the yaml or json specification content from a different server than the one which served the original Javascript.
The following are the next steps:

1. Understand whether it is possible to restrict the Cross Origin requests to Content-Type for JSON (and YAML). Apparently github returns text/plain for the sample yaml file.
2. Understand whether this is a security issue: downloading arbitrary application/json and text/plain content from other websites. Regardless of the content-type being returned, we're potentially causing server side logic to execute for our request.
3. If we're happy with the previous steps, understand how to configure this both on NGINX (for the container) and for the local server (Node.js based) used for development.

@ioggstream

[ioggstream]

CC: @bfabio @berez23 for security considerations and solutions related to node/js.

1. if the current use cases works, it's ok. Consider that yaml has not a standardized media-type yet;

2a. Currently developers.italia.it/it/api uses swagger-ui, where files are only processed on browsers and not on servers.
Using "safe" parsers (eg. that do not instatiate classes ... ) and OAS validators should provide basic guarantees that OAS/schema files are not going to execute arbitrary code.
2b. In general, I do not expect js to be able to be executed server-side: all the schema rendering process should happen in browsers;
2c. It could happen that, if there's a bug somewhere, an attacker capable of injecting a file into an administration repository could trigger the client to make requests to NDC: those requests should always be unauthenticated and public.

3. I think REST APIs should have CORS enabled (eg. see the playground api ). Should the rest of the website allow CORS instead?

[ronytw]

Here is the rendered page: https://ndc-dev.apps.cloudpub.testedev.istat.it/semantic-assets/details?uri=https%3A%2F%2Fw3id.org%2Fitalia%2Fschema%2Fperson%2Fv202108.01%2FOAS3

[ronytw]

Please @spuliz @ioggstream , can you review the linked page and, once the security questions have been answered, this issue can be closed.

[ioggstream]

fixed. See #127 for further improvements.