I'm using Google's SW-Toolbox library in my app for handling service worker duties; however, whenever I try to load a video from Parse (using Parse for file hosting), I get a series of CORS-related errors in the console and the video doesn't display. I know SW-Toolbox is involved because when I remove the service worker, or in browsers where service worker is not supported, the video loads fine. Could anyone help decipher these errors, and/or provide a workaround? Thanks.
My code for rendering the video is literally just the HTML5 video element:
<video src="https://files.parsetfss.com/0e1eb489-e25d-429b-86a9-d75a65253a09/tfss-1eedfc22-4219-443d-9f16-0d879f2c378a-Taylor%20Swift%20-%20Blank%20Space.mp4" controls>
NOTE: this isn't just a Parse issue; I tried another random mp4 URL from the web (http://techslides.com/demos/sample-videos/small.mp4) and had the same exact issue.
The first error, "Fetch API cannot load…", says that your service worker is intercepting the request for the video, which is a cross-origin request, and attempting to fetch the file itself; but the server doesn't permit cross-origin requests, so the fetch is failing.
This sounds a lot like sw-toolbox bug https://github.com/GoogleChrome/sw-toolbox/issues/49, which is affected by Chrome bug https://bugs.chromium.org/p/chromium/issues/detail?id=546076.
The suggested workaround in https://github.com/GoogleChrome/sw-toolbox/issues/49#issuecomment-170868923 is to not call event.respondWith() in the fetch handler for the request, which for sw-toolbox means ensuring that you don't define a route that handles the request with event.respondWith() (neither a specific route nor the default route).
Related
We have a WordPress blog running under via a reverse Proxy under ourdomain.example.com/blog which embeds YouTube videos.
Now we are seeing requests in the chrome network tab to
POST https://ourdomain.example.com/error_204?a=logerror&t=jserror&type=SyntaxError&msg=Failed%20to%20execute%20%27postMessage%27%20on%20%27Window%27%3A%20Invalid%20target%20origin%20%27data%3A%27%20in%20a%20call%20to%20%27postMessage%27.&line=Not%20available&level=WARNING&client.name=1
This requests lead to problems in our main software (Magento, under '/', showing CSRF problems)
We could just block those requests in the server but we want to understand why they are made.
Did anybody see those requests before?
The YouTube player is apparently attempting to send an internal error report to Google servers, via the endpoint http://youtube.com/error_204, http://youtube-nocookie.com/error_204 or similar. For that purpose, it uses the relative URI /error_204; but for some reason, this relative URI is resolved relative to your domain name, not YouTube’s.
What you should do is ensure that the link to the YouTube video points to YouTube’s domain, not your own. I presume that this is a problem with the configuration of the reverse proxy, but I am unable to say much more without further detail.
The error is originating from YouTube trying to access something on data: which isn't https, or potentially the video is not visible when loaded.
Just search for data: in your project, I don't know what you've got that would be using it.
The error message itself is fairly unhelpful.
The reason was a wrong embed code of the YouTube video
<iframe width="600" height="560" &" frameborder="0" allowfullscreen="" allow="autoplay" data-src="https://www.youtube.com/embed/xxxxx?
There was a wrong & sign, caused by some WordPress template builder
I'm building a web audio player like SoundCloud footer player using jQuery and HTML5 audio tag. The only-one problem is how to stream an audio file from another domain? (This player plugin could be installed in any website with some basic setup in JSON).
This is the console response when trying to stream an audio file:
The expected answers should be in jQuery.
Update: I've tried to use 'crossdomain' html5 attribute and crossDomain property in jQuery.ajax() but no effect.
Thanks a lot.
A couple routes...
Firstly, if you're not reading that audio data or doing anything client-side with that audio, you can just use <audio src="..." /> as normal. CORS doesn't come into play until you're actually trying to use script to read that audio. If you're using some sort of special player code... don't. Just use a normal HTML5 <audio> tag or the Audio class.
Next, if you do need to read the raw audio data, either direct from the URL or to record/process the resulting decoded audio, your server must be configured to allow for CORS for this resource. Access-Control-Allow-Origin: * in the response headers is the easiest way to get there, but you should read up on CORS and understand it before proceeding so that you don't accidentally make something insecure on that server.
The idea is quite simple in concept:
I would like to create a userscript that will let me press a button and save something on the page(most commonly and problematically images).
Note: A userscript is a script that is injected client-side(by browser extensions such as Tampermonkey and Greasemonkey) and is used to add functionality to a site.
To do so I merely need to call the saveAs() function and pass it the data.
The question then becomes how to I obtain the data.
Most approaches I've seen run into the situation where the resource is not of the same domain as the script perhaps?(not sure how this works).
Now, Tampermonkey(and Greasemonkey) have created a function to deal with this problem specifically - GM_XMLHTTPRequest, which can circumvent the need for proper CORS headers.
This however creates another request to the server, for a file that has already been downloaded.
My question is: Is there a way to not have to send secondary requests to the server?
Here is a chronicle of my efforts:
From what research I've managed to do, you can create a canvas and draw the image in there. However this "taints" the canvas, preventing it from running functions that extract that data(such as .toBlob() or .toDataURL()).
CORS offers 2 mechanisms as far as I understand it: Setting the proper HTTP headers, which requires control of the server, and a special attribute that can be put on HTML elements: crossorigin
I tried adding this property post-load and it won't work, you still get a tainted canvas.
Tampermonkey offers several different options on when to run the script. So the next idea was to run when the DOM is loaded, but the resources haven't yet been fetched. It seems the earliest this is possible is document-end(earlier the getElementById call returns null). However this currently returns an error when loading the image on the page(before any other additional code is run):
Image from origin '...' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '...' is therefore not allowed access.
There's also the --disable-web-security flag in Chrome, but I'd rather not go there.
No, there is no way to do it without a new request to the server.
When the first request is made, the image is marked as unsafe by the browser, and will then block a few features, like canvas' toDataURL, getImageData or toBlob, or in case of audio files, AudioContext's createMediaElementSource and AnalyserNode's methods and probably some others.
There is nothing you can do to circumvent this security, once it's marked as unsafe, it is unsafe.
You then have to make a new request to the server to get a new file from the server in safe way this time.
Commonly, you would just set the crossOrigin attribute on the media element before doing the request, and after the server has been properly configured to answer to such requests.
Now in your case, it seems clear that you can't configure any server where your script will be used on.
But as you noticed, extensions such as GreaseMonkey or TamperMonkey have access to more features than basic javascript ran from a webpage. In these features, there is one allowing your browser to be less careful about such cross-origin requests, and this is what the GM_xmlhttpRequest method does.
But once again, even extensions don't have enough power to unmark non-safe media.
You must perform a new request, using their less secured way.
I wanted to integrate the Youtube Data API in my application. For the same reason, with reference to the following link,
https://github.com/youtube/api-samples and create my client id and tried running the code.
I am working with Javascript + HTML. While running the code I am getting the following error.
Load denied by X-Frame-Options: https://accounts.google.com/o/oauth2/auth?client_id=AIzaSyARXJSURlAnAm48f3uXok0rB7GrEGb3pLc&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube&immediate=true&include_granted_scopes=true&proxy=oauth2relay311121687&redirect_uri=postmessage&origin=http%3A%2F%2Flocalhost%3A8080&response_type=token&state=475509781%7C0.2158929842&authuser=0 does not permit cross-origin framing.
Can anyone suggest me what went wrong and how can I fix the same.
Try to break down your requested URL to the minimum. Maybe there is one GET that conflicts with other configs.
I have been trying to get this to run correctly so days now with no luck.
I have created a custom audio player, that accesses an MP3 on a S3 Amazon server. The audio player has custom controls enabled by Javascript, and a Audio Visualizer made possible by the Web Audio API.
Now the problem I am running into is this: Work fine on Chrome. Safari out right says it can't run the Web Audio API, but the audio will still play. In Firefox, the entire thing shuts down. Click play... nothing. I thought it was a CORS issue, so we set the proper headers on the server and still nothing. BUT... if I deactivate the Web Audio API visualizer, then I can get the player to play just fine.
http://jsfiddle.net/murphy1976/yqqf7uL1/1/
Here is my jFiddle. I have separated the Audio Player controls Script from the Visualizer Script with comments so you can see how it will work in Firefox, and how it will NOT work in Firefox.
I read somewhere that this issue that I'm running into MAY be a bug with Firefox. I just want to make sure so that I can stop beating my skull over this.
Could I put a call to CORS here?:
<source crossorigin="anonymous" src="audioFiles/35022797.mp3" id="srcMP3" type="audio/mp3">
The same-origin policy says that scripts run on some origin cannot read resources from another origin. (An origin is a domain, plus a scheme and port, like http://foo.example.com:80.)
Note that the same-origin policy does not prevent cross-origin media from being displayed to the user. Rather, it prevents scripts from programmatically reading cross-origin resources. Consider the <img> tag: a page on example.com can show a cross-origin image from other.com, but a script on example.com's page cannot read the contents of that image. The user can see it; the page cannot.
The Web Audio API can read the contents of audio files. If an audio file is from a different origin, this kind of reading is not allow by the same-origin policy. A user can listen to a cross-origin audio file, but a script on the page cannot read the contents of the file. When you attempt to feed a cross-origin audio file into an analyzer script (e.g., so that you can draw a visualization on a canvas), the same-origin policy should stop you. You are attempting to violate the same-origin policy, and the browser is correctly stopping you by refusing to play the audio in way that would allow you to read the file contents.
Note that Chrome does not prevent such cross-origin file reading for audio files, and this is incorrect behavior.
The correct solution is to have your media servers serve the audio files with a CORS Access-Control-Allow-Origin: * HTTP response header. However, this currently does not work in Firefox, which is incorrect behavior. If Firefox hopes to have a compliant implementation, this will be fixed eventually.
Confirmed that there is a bug in Firefox for using the createMediaElementSource method on a cross domain source:
https://bugzilla.mozilla.org/show_bug.cgi?id=937718