CORB response from javascript tracking code

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>
n.src=w;g.parentNode.insertBefore(n,g)}}(window,document,"script","// /<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<bucketnameredacted>/trackers/js/2.14.0/sp.js&followup=<bucketnameredacted>/trackers/js/2.14.0/sp.js with MIME type text/html. See 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?

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.

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!

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.

Looking in more detail at the CORB error, it looks like it is redirecting you to a log in screen.<bucketnameredacted>/trackers/js/2.14.0/sp.js&followup=<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.

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

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

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.

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.