search

csaf-poc / csaf_webview

Web app (module) to display a CSAF 2 document and to browse CSAF 2 ROLIE feeds. ⚠️ The web demo is often not allowed to access servers:
https://csaf-poc.github.io/csaf_webview/
1 stars 3 forks source link

How to deal with disallowed cross origin resource-sharing (CORS) #15

Closed bernhardreiter closed 8 months ago

bernhardreiter commented 9 months ago

It seems servers in the wild often do not allow a single page application via a web browser by not setting the Access-Control-Allow-Origin: * header.

The header is not yet required by the CSAF 2.0 standard. As it would make sense we've suggest this in https://github.com/oasis-tcs/csaf/issues/653 .

At least the BSI and Redhat did not provide he needed ACAO headers so an application just served via github pages will not be able to load the files from them (neither single documents, nor ROLIE feeds).

So we need a proxy until the CSAF standards and implementations change. In a development setup, this is not a problems, as we can use the serving node.js development server to do the additional proxying work. But this is a high requirement for people that want to use this product.

Do we need a) a way to deploy this on a single machine, then we could look for a small proxy application to run on localhost or b) instruction and software for a public setup, which means a server with CPU bandwidth and protection against abuse for the proxy work ?

ThomasJunk commented 9 months ago

proxy

To address this feature I have added the possibility to add a proxy URL in the UI.

For development purposes one could enter the full URL or the pathname /proxy to use the development servers capabilities. For development purposes there is a working default configuration. And in the README.md is a section mentioning configuration forwarding to vite configuration.

bernhardreiter commented 9 months ago

In case the permissions of the server that was asked forbid to load the resources, we shall issue an error message like:Failed to load from URL. The server may be unreachable or the resource cannot be accessed due to CORS restrictions.

Once implemented, we are good and can close this issue.

bernhardreiter commented 8 months ago

This is only partly implemented in src/lib/urlloader.ts. According to https://developer.mozilla.org/en-US/docs/Web/API/fetch#exceptions we should make the message specific to a type error (in addition of giving the error type and message.

ThomasJunk commented 8 months ago

This is only partly implemented in src/lib/urlloader.ts. According to https://developer.mozilla.org/en-US/docs/Web/API/fetch#exceptions we should make the message specific to a type error (in addition of giving the error type and message.

This requirement is also part of https://github.com/csaf-poc/csaf_webview/issues/23 As of now a proxy solution is out of scope and having the proxy solution for development purposes documented I close here