Notes-API: Cross-Origin Request Blocked

10

#1

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?


#2


#3

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?


#4

You can try this config option, if you have access to server. https://github.com/owncloud/core/blob/master/config/config.sample.php#L74


#5

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.


#6

sorry for uncertainty, now I added link to my previous comment.


#7

I already found & tried this, but without any success.

Which domain should I add there? The clients domain?


#8

Yes, you should add each client domain address, by the way don’t forget to http or https. It should work.


#9

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. :worried:


#10

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.


#11

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?


#12

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.


#13

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 …


#14

I did the same try with localhost. -> BLOCKED


#15

Can you send me the request and response? Maybe as screenshot from the firefox debugger?


#16

Maybe later. I have to leave now.


#17

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?


#18

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


#19

I think it is valid, as it is accepted by the validator function. :wink:

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.


#20

We can add a fix to accept any request from a moz extension.

I need to do some research about the impact.