I have trouble with the Notes-API, starting after the upgrade from oC 9 to oC 10.0.8. Under v9.x everything worked, but at v10 the API (GET) always fails.
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://somewhere/index.php/apps/notes/api/v0.2/notes?exclude=content. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Due to the fact, that the GET works if done by curl, let me think, hat my code is missing something. But what? Can this Cross-Origin thing be configured somewhere?
Thanks for your reply. Of course I know this input box and the add button. Unfortunately this doesn’t accept anything. No effect, on none of my 3 oc10 instances.
[edit] Is the use of this feature mentioned somewhere in the docs?
Do you meant that whitelist thing above? Doesn’t work, or at least I cannot figure out how or why. I’m seeking more info/docs.
sorry for uncertainty, now I added link to my previous comment.
I already found & tried this, but without any success.
Which domain should I add there? The clients domain?
Yes, you should add each client domain address, by the way don’t forget to http or https. It should work.
Hmm, most of my clients have dynamic addresses…
[edit] It doesn’t work either, even if I add my dynamically assigned domain there. I’m still getting that
Cross-Origin Request Blocked
message. 
Well, the best solutions, are those, that I found by myself!
I had to adjust mi code, to deal with hat CORS-thing.
OTOH, it had been nice, to find such heavy changes between versions (9 -> 10) somewhere in the docs/release notes.
Just my 2 cents.
CORS is only relevant to web applications which access the notes api from a different domain.
@alfredb you are accessing the api from an android app - right?
I’m afraid I don’t fully understand this. My firefox webextension is running on my Laptop, connected to the internet from everywhere. Therefore it was somewhat surprising, that my access was blocked by the CORS-preflight thing.
Depending on the request lib you are using there might be an impact to the behavior outside your immediate code control.
I did a quick test and the CORS preflight requests have been working for me …
oh wait - this might have been related to the fact that I’m using localhost. Let me try again …
I did the same try with localhost. -> BLOCKED
Can you send me the request and response? Maybe as screenshot from the firefox debugger?
Maybe later. I have to leave now.
I repeated the tests.
- Server: localhost
- Client: localhost, Firefox with unmodified webextension from AMO
It fails with the unmodified code, with the well-known message (console).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost/owncloud/index.php/apps/notes/api/v0.2/notes?exclude=content. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
But if you add the value of the origin value, in my case moz-extension://24e15b45-d986-4db8-a1f8-23917bcd638c, to the list of “white” domains, then it works.
Please find the whireshark protocols at pastebin:
So the question remains: Why is such a request blocked at all?
I’m not too sure if such an origin header is valid - https://tools.ietf.org/html/rfc6454#section-7
we could limit our CORS checks to http and https schemas only … I need to double check this
I think it is valid, as it is accepted by the validator function. 
But even worse: This is NOT the ID of the add-on published at AMO. I depends on the FF profile, means that I would have one whitelist entry for every client I’m using.
We can add a fix to accept any request from a moz extension.
I need to do some research about the impact.
