Allow User-Agent header as well in Access-Control-Allow-Headers

[ovanwijk]

The line below sets

iri/src/main/java/com/iota/iri/service/API.java

Line 136 in 29378a5

exchange.getResponseHeaders().put(new HttpString("Access-Control-Allow-Headers"), "Origin, X-Requested-With, Content-Type, Accept, X-IOTA-API-Version");

         Access-Control-Allow-Headers : "Origin, X-Requested-With, Content-Type, Accept, X-IOTA-API-Version" quite fine, however! It misses the User-Agent header in that list. 

This is a problem because Safari enforces the User-Agent header on Access-Control-Allow-Headers. All other browsers ignore it except Safari, Firefox does for example the following when executing:

         x.setRequestHeader('User-Agent', '' (or null)):  "User-Agent | node-XMLHttpRequest, null"

Meaning that even if you can change it, it is very obvious that you did and the browser still sends the header!

This has a consequence that no safari browser can make CORS requests to other nodes!
Should be a small fix

[ovanwijk]

PS I have the same issues on Firefox on Ubuntu. So the issue is a bit larger then expected. (Firefox on windows worked somehow)

[jakubcech]

Hi, thanks for reporting this. We usually recommend tools that allow for more control over the requests to avoid something like this. Browsers unfortunately do things their way. If you're able to do a PR that fixes this yourself, then we'll be happy to review. Please see the contribution guidelines for that. I'm closing the issue until then as we wouldn't get to this specific bug anytime soon.

However, we'll be revisiting the whole API stack in the near future and I think we might revisit how the 'server' treats request headers as I think there shouldn't too be hard requirements on what gets accepted as long as it follows RFC7231.

[ovanwijk]

Ok I will see if I can set everything up to do this change, it is really minimal after all (literally a value added in a list).

But what is the point of enabling cross domain headers if the browser is not 'the target'? Tools with more control generally just ignore it anyway (since those are calls from the machine and thus not from an actual domain). Might as well not include them at all.

Cross-domain is specifically to force browsers to act in a certain way against malicious actors calling api's on other domains by (for example)copy-cat sites. IOTA nodes don't have this problem hence the wild card. But if the 'Access-Control-Allow-Headers' don't include the headers that are sent by default by browsers it seems like a bug to me. Point is that some implementation are less strict on this (like chrome doesn't check for this (blink engines)) while other do. Right now only Chrome users can still use IOTA from the browser.

This issue is relatively new as shown by a github api issue: https://github.com/octokit/rest.js/issues/817

The missing header is a bug if the intent is for IOTA-libs to work in browsers, which seems to be the case since cross-domain headers are included.

To give some more background: https://iota-pay.net uses iota-nodes in the public domain from the browser. Right now only users with Chrome can use it, this is true for iota-pay but potentially all software that wants to make use of public nodes from the browser.

I will see if I can get everything running to make a pull-request for this,