Since jQuery ajax ist not working for CORS/IE, I'm using XDomainRequest to retreive data from another Server. Work's fine, but I would like to send some header ('Authentification', 'content-type').
Is there a chance to add/change header in XDomainRequest?
Or does someone know a workaround?
This is what we did for IE.
If you have control over the target domain, host a (static) html file there. Include the html using the iframe.
Now this iframe does actually have access to the local domain, so you can communicate between the parent and child frame to get what you need.
This worked much better than XDomainRequest for us.
window.postMessage is the best way to setup the communication:
But I'm pretty sure that only started working since IE8. If you require older browsers as well, you must use a different hack.
In our case, this was our 3-layer system:
CORS, for browsers that support it
An iframe & window.postMessage as a primary fallback
A server-side proxy script as the secondary fallback
All of these options work well, are reliable and didn't feel too much like a hack. The secondary fallback was barely ever used.
Keep in mind that the 'Authentication' header specifically is special, and I would not be shocked that that's blocked under certain circumstances anyway. We added a custom header 'X-Authenticate' as it did pass through all the time.
IE's XDomainRequest does not allow custom headers to be set. See item #3 here: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx The XDomainRequest object is locked down to the point where it is difficult to make authenticated requests.
Related
I have a situation where I have an iframe hosting a third-party site. I need to pick up only that the iframe has navigated to its final "success" url, so I can respond.
However, as you may know, modern browsers prevent you from accessing the iframe document object, even the location, because of CORS security issues.
Right now, I am running a counter in the onload event of the iframe, and performing my response when the counter hits a certain number.
But this is very hacky and won't be reliable enough for a new situation where I am having to use this mechanism.
So I'm looking for some wizard to tell me a better way. I just need to know when it's reached a certain URL.
BTW jquery is not an option; this is an Angular2 app.
Thanks!
frood
If you control both parent and embedded websites (And don't have to support very old browsers) I would consider using the postMessage API. It enables simple event communication between the parent and the child.
Here is a nice simple example - link
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 want to do a PUT request across a different domain. But the script fails only in IE.
I figured out what the problem was, in IE if you look at Internet Options > Security tab > Custom level > Miscellaneous > Access data sources across domains option was set to disable. The only way I was able to get my put request work is setting that option to Allow.
So my question: Is there a way I can get this working without enforcing end users to set the option?
There is XDomainRequest() which can be used for XDomain requests in IE but, this method doesn't support PUT.
IE9 and older does not support PUT method in cross domain request. Only GET and POST.
You could use a library like Xdomain or EasyXDM to get a CORS alternative using the Post Message hack.
I prefer to use Xdomain because it hijacks the native XMLHTTPRequest and provides a "drop-in" solution. EasyXDM forces you to use their API which means more conditional coding overhead, however, it supports IE6/IE7.
The main take away? Don't stop supporting CORS! Just make IE behave itself and opt-in to the future.
I have a page where I don't want the outbound links to send a referrer so the destination site doesn't know where they came from.
I'm guessing this isn't possible but I just want to make sure there weren't any hidden javascript magic that could do it and that would work with some (if not most) browsers.
Maybe some clever HTTP status code redirecting kung-fu?
Something like this would be perfect
link
The attribute you are looking for is rel="noreferrer": https://html.spec.whatwg.org/multipage/links.html#link-type-noreferrer
According to https://caniuse.com/rel-noreferrer, all the major browsers have supported it since at least 2015, though Opera Mini does not (and, of course, some users may be using older browser versions).
For anyone who's visiting in 2015 and beyond, there's now a proper solution gaining support.
The HTTP Referrer Policy spec lets you control referrer-sending for links and subresources (images, scripts, stylesheets, etc.) and, at the moment, it's supported on Firefox, Chrome, Opera, and Desktop Safari 11.1.
Edge, IE11, iOS Safari, and desktop versions of Safari prior to 11.1 support an older version of the spec with never, always, origin, and default as the options.
According to the spec, these can be supported by specifying multiple policy values. Unrecognized ones will be ignored and the last recognized one will win.
<meta name="referrer" content="never">
<meta name="referrer" content="no-referrer">
Also, if you want to apply it to audio, img, link, script, or video tags which require a crossorigin attribute, prefer crossorigin="anonymous" where possible, so that only the absolute minimum (the Origin header) will be shared.
(You can't get rid of the Origin header while using CORS because the remote sites need to know what domain is making the request in order to allow or deny it.)
HTML 5 includes rel="noreferrer", which is supported in all major browsers. So for these browsers, you can simply write:
link
There's also a shim available for other browsers: https://github.com/knu/noreferrer
Bigmack is on the right track, but a javascript location change still sends a referrer in firefox. Using a meta refresh seems to solve the problem for me.
</html>'>Link
I was trying to figure this out too.
The solution I thought of was to use a data url to hide the actual page I am coming from.
<a href='data:text/html;charset=utf-8, <html><script>window.location = "http://google.ca";</script></html>'>Link</a>
This link opens a page that only contains javascript to load a different page.
In my testing no referrer is given to the final destination. I don't know what it could send as a referrer if it tried anyways, maybe the data url ? which wouldn't give away where you came from.
This works in Chrome. Chrome is my only concern for my current problem but for browsers that don't like javascript in pages that are data urls. You could probably try a meta refresh.
In addition to the information already provided. Lots more information on the topic here: https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-no-referrer
Specifically allowing you to either send or not send referral information if you need different rules for same-origin or cross-origin requests.
Something to consider depending on your specific use case. i.e. if you are pulling in images/css/javascript from 3rd party websites, then you may want to not identify the URL that you are doing this from and hence would use the no-referrer option. Whereas if you are linking out to other websites from your own website, you may want them to know that you are sending them traffic. Always think through the implications of this on both sides. If there is a conflict in these two areas, then there are other options such as adding UTM tracking parameters to the end of URLs which may come in handy for some people. Full details here: https://www.contradodigital.com/2014/06/03/importance-utm-tracking-parameters-social-media/
I don't know if I'm missing something here and am v happy to be corrected, but wouldn't a URL shortening service meet your needs here?
Presumably the logs at the destination site would only show the domain of the shortening service, not the initial referring domain, so you would remain hidden.
We have application hosted "xyz:8080/rootapp" and cometd services hosted on "xyz:9090/cometed". The JavaScript loaded from cometd server needs to access the DOM/JavaScripts loaded from (xyz:8080), the browser's same origin policy is not allowing it.
To overcome it we set 'document.domain' as "xyz" eliminating port. This solution is working well but this is becoming problem to all the iframes loaded by "xyz:8080" and I need to change each and every iframe to use domain as "xyz".
Can someone provide me hints to solve this problem without changing each and every iframe?
Do we have any http header to set domain?
You can use CORS to specify an exception to same origin, this will work in any relatively modern browser.
This page has a fairly good intro and a list of compatible browsers.
The short version is put an Access-Control-Allow-Origin header into the responses from xyz:8080 that contains either xyz:9090 or * (for unrestricted access).