Vintage.js: remote images - javascript

Plugin only applies filter to files on my server, but with remote images:
Unable to get image data from canvas because the canvas has been tainted by cross-origin data.
How to fix it?

The error you are receiving is part of the browser's built-in security mechanisms to prevent hackers from using remote data to manipulate sites. You can't get around it (and if you could, it would be a major security hole that the browser makers would be very quick to fix)
To confirm this, the same question has already been asked on the Vinatge.js website (as a github issue ticket), and the answer given by the Vinatge.js author was that it isn't possible to load remote images.
Sorry to disappoint you.
The work-around given was to use a proxy loader on your own server to load the images so that they are not given to the site as remote images.
In some cases, it may in fact be possible. It is possible for the remote server to be configured to allow it. However this configuration would need to be done on the remote server, so if you don't have access to that then the problem remains.

Related

Setting custom referrer for the request made from <img> tag

Sometimes websites won't let you load images without a valid referrer. Take this as an example, it returns a forbidden error. In a similar question I have found this answer, that suggests doing something like this:
<img src onerror="fetch('https://i.pximg.net/img-original/img/2020/11/28/06/04/23/85949640_p0.png', {headers: {Referer: 'https://www.pixiv.net/en/'}}).then(r=>r.blob()).then(d=> this.src=window.URL.createObjectURL(d));" />
This however, still fails to load the image. Checking the code of some extensions that promise to fix this error by installing scripts shows that they're just changing the referral, and that this should get things working.
Sometimes websites won't let you load images without proper a referrer.
Yes. Plenty of websites do not want to pay to store images and transfer them over the network so that freeloaders can display them on their websites without shouldering the cost.
In a similar question I have found this answer, that suggests doing something like this
That fails for two reasons.
It is a forbidden header. Browsers are designed to prevent your JavaScript from lying about where requests are being triggered from.
Most sites hosting images don't grant permission, via CORS, to third-parties to read them with JS. They are even more unlikely to if they do referer checking to stop freeloading!
If a website doesn't want you displaying images they host, you need to respect that.
Pay for your own image hosting instead.
Don't copy the images from the third-party to your own site unless you are sure they aren't protected by copyright (or you have permission).

Create a "Save As" userscript

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.

Requested file in Javascript downloading to the user's computer rather than being read

I am trying to perform a hack, what my primary goal is to get the mp4 links of youtube videos. In past, I have been downloading the text file from http://www.youtube.com/get_video_info?video_id=videoidand extracting the links from there, this works in the apps but in browser its not possible because its a cross site request and browsers do not allow it.
To counter this I used easyXDM, now the problem is the file is being downloaded on the user's machine instead of opening in Javascript. Here's the easyXDM code
$(document).ready(function(){ var socket = new easyXDM.Socket({
remote: "http://www.youtube.com/get_video_info?video_id=PBOBJRto728", // the path to the provider
onMessage: getVideo
});
});
Here's the page http://www.voltsoft.com/default.html, you can go there and see what's happening.
How can I read the data from the file in javascript?
easyXDM is not going to faciliate your needs. In order for easyXDM to function you need it hosted on the two domains you want to communicate between. In this case you need it on both voltsoft.com and youtube.com. You can't use easyXDM here because you can't upload arbitrary HTML/JS content to youtube.com.
Generally the solution in this situation is that you either need to proxy the remote contents server-side or you need the cooperation of the remote server.

stop ie showing security warning when loading non secure images on secure page

I am using the following JQuery plugin to load an image slider http://www.orionseven.com/imageloader/index.php
However this is on a secure page (https) although the images are from external urls so therefore are not on secure pages. Is there anyway I can stop IE 7 displaying the security warning? Maybe changing my code or something?
You cannot disable those warnings.
The reason you're seing them is because the user should be notified that non-secure requests are being made (and potentially compromising the security in the process). Turning them off would be bad for the user.
You should probably be hosting the images on your local server rather than expecting a third party to host them for you. That way they can all be served as HTTPS from the same site, and problem solved.
If you must fetch them from the third party server, you'll only be able to solve this issue if that third party also provides HTTPS on their server. In that case, you'd need to modify the URL used to request the images to change the protocol depending on what protocol the main page is being served with.
If you want to load them remotely and that remote server doesn't provide HTTPS, then you cannot get rid of the message -- it's there intentionally in IE to provide a legitimate security warning. You can't override it.
I have the exact same issue. Since M$ considers every single one of their users to be brain-dead and decided to lock-down the ability to bypass that warning, I've decided on a much simpler solution- Use literally any other browser. Check out this solution-
https://stackoverflow.com/a/23047482/3692082
You could proxy images through localy hosted php script.
https://server/image.php?url=foobar.com/foo.gif
<?php
echo file_get_contents("http://".$_GET['url']);
?>
some comments about cross-site-scripting vulnerability should follow:)

Avoid same Javascript / CSS file load on different pages of a website

We have multiple pages on a website which require many of the same Javascript and CSS files.
How do we avoid those files being downloaded again if it has already been downloaded by the user browsing some other page?
If the file is in the same path, the browser should automatically cache it. You may want to explicitly specify the cache expiry time, if possible via your web server or programming environment.
If you use an HTTP traffic analyzer like Fiddler you should see that requests for JavaScript and CSS resources return an HTTP code 304 (Not Modified). This tells the browser "the version of the resource you have in your cache is the same as the one on the server so you don't need to download it again".
For even better performance you can explicitly set caching headers for these resources.
This caching tutorial has great info.
You should explicitly set caching headers if you want caching. www.fiddler2.com/redir/?id=httpperf

Categories

Resources