Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Access-Control-Allow-Credentials CORS header #6970

Closed
Marc3001 opened this issue Jan 12, 2018 · 13 comments
Closed

Missing Access-Control-Allow-Credentials CORS header #6970

Marc3001 opened this issue Jan 12, 2018 · 13 comments

Comments

@Marc3001
Copy link

We are using raven-js to push events to sentry.io platform.
When a new event is pushed, Access-Control-Allow-Credentials CORS header is missing from sentry server response and so response content is blocked by browser.
As requests are POST ones and response seems to not be actually processed by raven-js this is non-blocking but it is polluting browser console and will possibly cause issue when raven-js will need response content.

See below complete error displayed by browser :
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://sentry.io/api/:id/store/?sentry_version=7&sentry_client=raven-js%2F3.22.0&sentry_key=:key. (Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’).

@mattrobenolt
Copy link
Contributor

Do you literally have :id in your DSN?

@mattrobenolt
Copy link
Contributor

Also, from our perspective, we don’t need this header and isn’t required to use raven-js as you mentioned. What is triggering the logs you see? Is that due to strict stuff on your site? I’ve never seen this before or reported by anyone else. I’d rather not add more CORS stuff that we don’t actually need without a reason. But this is probably trivial enough to just add.

@Marc3001
Copy link
Author

Marc3001 commented Jan 12, 2018

No I do not have :id in logs ;) I removed personnal ids from logs.

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials documentation about this header.
This is mandatory CORS header if request is containing authentication headers or just cookies.
As raven-js request is containing cookies, without this header the response content is blocked by my firefox browser.

@Marc3001
Copy link
Author

Note that I was able to reproduce this on firefox57 and chromium63 with default settings (I didn't make any customization about security or features on these browsers).

@mattrobenolt
Copy link
Contributor

This is mandatory CORS header if request is containing authentication headers or just cookies.
As raven-js request is containing cookies, without this header the response content is blocked by my firefox browser

Right, my point is this request doesn't actually use and cookies to report anything. Nor do we read the response back. So this shouldn't be actually impacting anything.

But with that said, I don't really see the harm in adding this header, I just have never seen this be an issue before.

@mattrobenolt
Copy link
Contributor

On second thoughts, doesn't it feel better that we're explicitly not allowing cookies to be sent? It seems better from my perspective that we're not tracking extra stuff about your users or something through cookies. Is there something we can do to make this not yell loudly if this is intended behavior?

/cc @benvinegar ?

@Marc3001
Copy link
Author

OK so issue is maybe in raven-js side then as lib should not send cookies and then browser will not block response...

@mattrobenolt
Copy link
Contributor

Right, but we're not explicitly doing that. iirc that's just normal browser behavior. I'll bring it up with @getsentry/sdks team and see if there's anything we can actually change here to explicitly work around this so it's less noisy. This is the first I've heard of this or seen, so not sure if something new changed or browsers just recently started being noisier about this.

@jan-auer
Copy link
Member

@kamilogorek will know more about this, but here's some starting points:

  • By default, XMLHttpRequests will not include credentials
  • The fetch API, which we started using recently if available, has the same default
  • In Add fetchParameters to configure fetch sentry-javascript#1177, we added credentials: include as a default. However this only applies if fetch is present (which is true for modern browsers). From the PR it seems that this was added for a self-hosted Sentry instance. I guess this didn't break before, as the cookie is only ever present if the user was logged in to Sentry before.
  • To avoid this issue temporarily, you can pass fetchParameters: { credentials: 'omit' } when configuring Raven. But I think we should change the default.

@mattrobenolt
Copy link
Contributor

Ah, that makes sense. Yeah, I think if on-premise needs cookies, they should be the exception and pass custom fetchParameters since the the majority use case doesn't need this.

@mattrobenolt
Copy link
Contributor

I'm going to go ahead and close the issue here since the raven-js PR should address this.

Thanks everyone! <3

@kamilogorek
Copy link
Contributor

Fixed in 3.22.1, sorry for the inconvenience.

@Ramblurr
Copy link

For those coming from google, the error is probably something like:

The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. Origin 'https://<your domain>' is therefore not allowed access.

The fix is in raven 3.22.1, see the release notes

@github-actions github-actions bot locked and limited conversation to collaborators Dec 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants