CORB response from javascript tracking code

For engineers Tracking SDKs
1

I don’t know if this has previously been addressed, but I’m hosting the snowplow javascript tracker in a GCP storage location, using the tracking code:

<script type="text/javascript" async=1>
;(function(p,l,o,w,i,n,g){if(!p[i]){p.GlobalSnowplowNamespace=p.GlobalSnowplowNamespace||[];
p.GlobalSnowplowNamespace.push(i);p[i]=function(){(p[i].q=p[i].q||[]).push(arguments)
};p[i].q=p[i].q||[];n=l.createElement(o);g=l.getElementsByTagName(o)[0];n.async=1;
n.src=w;g.parentNode.insertBefore(n,g)}}(window,document,"script","//storage.cloud.google.com /<bucketnameredacted>/trackers/js/2.14.0/sp.js","sp"));

…

This seems to currently be resulting in a CORB error in Chrome:

VM3212:1 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://accounts.google.com/ServiceLogin?service=cds&passive=1209600&continue=https://storage.cloud.google.com/<bucketnameredacted>/trackers/js/2.14.0/sp.js&followup=https://storage.cloud.google.com/<bucketnameredacted>/trackers/js/2.14.0/sp.js with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.

Does this mean that I have to host the tracking script on the same domain as the website (yes, I’m a noob and have little idea about CORS/CORB).

Is this warning ignorable?

2

Hi @rbkn
This should be possible.

Did you follow the instructions here?

Pay particular attention to the metadata attributes that are set, as I believe the error suggests you are returning a Content-Type of text/html rather than application/x-javascript.

3

Ah, thanks for this. No I missed part of these instructions (renaming/gzipping) and changing of the MIME type.

RTM for me I guess!

I reckon this will fix this, thanks!

4

Actually, went through the instructions and it looks like it didn’t fix it.
The metadata for the script is (and was for the previous uncompressed one) application/x-javascript.

The only difference I can think of is that this bucket does not use ‘fine grained’ access, but I was hoping that this only affects access to the file and not how it it served.

5

Looking in more detail at the CORB error, it looks like it is redirecting you to a log in screen.
https://accounts.google.com/ServiceLogin?service=cds&passive=1209600&continue=https://storage.cloud.google.com/<bucketnameredacted>/trackers/js/2.14.0/sp.js&followup=https://storage.cloud.google.com/<bucketnameredacted>/trackers/js/2.14.0/sp.js

This suggests to me that the access control you have on the file isn’t correct. You need to set the allUsers permission to make the file public.

6

Yes, I noticed that as well. This bucket does have allUsers with storageObjectViewer role applied to the bucket (with bucket-level permissioning applied).

image
image819×60 2.6 KB

The file itself has the public to internet icon also, however accessing it in incognito (without any auth) does bring up a login page.

image
image2216×101 9.89 KB

Seems like a GCP issue (or my lack of knowledge of bucket permissioning). Will play around with this and see if I can find a reason for it thinking a login is required.

7

This issue has resolved itself (I didn’t look at it further as everything else was ok).
I am guessing caching somewhere must have caused the continued issue after the initial fix.