-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
@sentry/vue breaks Google Analytics CORS policy #5868
Comments
Hi @9mm thanks for writing in! Interesting problem. Are you able to compare the outgoing GA requests when using the Sentry SDK vs. when not using it? AFAICT, the only thing we modify on outgoing requests is that we add headers, namely the |
Can you send me your email and I can email the site to you? Maybe you can also look internally at the Trace ID's below or something It's hard to tell regarding your question because when the request fails, it shows as 2 requests, OPTIONS / POST+Preflight. When the request works it shows as POST. From what I see they're mostly the same. BrokenPOST
OPTIONS
WORKINGPOST
|
I don't know if it helps, here are the 2 functions that sit above analytics.js in dev tools when you hover over "initiator" of the failed request, in order as they appear (the top being the most recent function in the exception chain) I know the code is minified but I'm sure you can figure it out from keywords in it, etc Req 1
Req 2
|
So, I think it kinda makes sense that you have two functions above because regardless of if we're modifying an outgoing request, we're instrumenting it (e.g. for breadcrumbs) by default. Just to have it written somewhere, these are the two functions: What I find interesting is that in your first request (labeled with Broken->POST), there are the two headers I was talking about earlier ( It's important to note that request URLs only have to partially match. For example: |
Sure, can you see my public email address on my profile? |
Yes.. that's actually a great point about the headers being sent on that request. I'm certain its to Google analytics: When clicking the request: Sorry for the cropping (Ill email you the domain) If I scroll down a bit i'm definitely seeing the baggage header on the same request As far as you mentioning "From" GA, I'm not sure what you mean by that (it's not a request originating from googles servers, its originating from our domain, but its being generated by the Here is the exact Maybe the problem is the last line? ... a regex matching
|
Hi @9mm, just to clarify, what I meant with "from GA" is that the Analytics script you're downloading is sending these XHR requests that cause the problem. So I think for now we should continue investigating why the headers end up in the request. The I took a look at the entries you sent me and I can't find anything that is directly responsible for it. Maybe (just guessing) GA puts your domain name or something that matches the entries in Also, can you set the |
I'm experiencing the same issue, and I'm also confused about the last entry in the tracingOrigins example: |
I just checked and for XHR requests ( const xhr = new XMLHttpRequest();
xhr.open("GET", "/api/user/5"); // the /^\// regex will match
xhr.open("GET", "https://someDomain.com/api/user/5"); // the /^\// regex will not match (but maybe another entry) Here's the relevant code: |
@andrisp Are you also using the Vue SDK? How does your |
@Lms24 yes, Vue 2.6.10 and Sentry 7.1.1.
I'm using "mydomain" for local dev/tests. By looking at the google analytics URLs which get blocked with the CORS error, they indeed have "mydomain" included somewhere in the query string, and there is the "bagage" header in the request. I'll experiment with better regex strings to match exact domains not parts of the full string. I think that the Sentry documentation could be improved about this (about |
That's probably what's causing the CORS error.
Agreed. I'll open up an issue in our docs repo to track this. Fwiw, we're going to replace |
To add to this, I'm currently almost certain that this is what's causing the problem. I just reproduced this behaviour by adding Sentry (Browser SDK) and SolutionThis means, if you use GA, you have to make more robust This is documented in our |
Ahhh!! Great thinking with realizing its also in the query string. Thank you!!! 🎉 I will do that now but that totally makes sense thats the problem so I'll close this pre-emptively |
Clarify the meaning of the JS SDK's default values for the `tracingOrigins` option of the `BrowserTracing` integration. As pointed out in getsentry/sentry-javascript#5868 ([comment](getsentry/sentry-javascript#5868 (comment))), it is not obvious on first glance, to which requests tracing headers are attached if the default values are used. This PR therefore adds an explanation and slightly changes the ordering of the `tracingOrigins` description. Co-authored-by: Isabel <[email protected]>
Clarify the meaning of the JS SDK's default values for the `tracingOrigins` option of the `BrowserTracing` integration. As pointed out in getsentry/sentry-javascript#5868 ([comment](getsentry/sentry-javascript#5868 (comment))), it is not obvious on first glance, to which requests tracing headers are attached if the default values are used. This PR therefore adds an explanation and slightly changes the ordering of the `tracingOrigins` description. Co-authored-by: Isabel <[email protected]>
@Lms24, FYI, Btw, not related to Vue; I'm using |
Hi @sassomedia It's a little hidden but #5285 tracks this future change along with other changes we want to make to control span and trace propagation on a more fine-grained level. If (for some reason) |
Ah ok, that makes sense then. I'm actually troubleshooting another issue so I've been scouring docs as well as GitHub issues and came across |
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which package are you using?
@sentry/vue
SDK Version
7.14.0
Framework Version
7.14.0
Link to Sentry event
No response
Steps to Reproduce
main.js
:analytics.js
form of Google Analytics code... This part isn't super important, all you have to know is that OUR code does not handle the ajax request (obviously, if you've ever used Google Analytics this makes sense). Instead, you interact withga
object provided by Google For example...ga
trying to make a CORS request...if you look at the exact reason it fails, its because Google responds with
Access-Control-Allow-Origin: *
but the request itself is usingwithCredentials: include
...I just thought what could "wrap" these requests which might be modifying them. I disabled sentry in main.js and the analytics requests now work perfectly
Expected Result
I honestly have no idea even WHAT is happening, or why Sentry would need to modify
withCredentials
on xmlhttprequests.... maybe that's not even happening, but but is triggering this error indirectlyThe expected result should be google analytics should work normally, like when sentry is not loaded
Actual Result
The actual way I found this is by looking at the error pasted above in chrome dev tools console. You will see the 'initiator' file of the error. Instead of analytics.js being the initiator (which youd expect), I noticed it was a babel chunk js file..... When I clicked either of these 2 exceptions below it brings me to Sentry code, which is telling me that whatever code Sentry is wrapping is breaking the way Google needs it to work
The text was updated successfully, but these errors were encountered: