I wonder if this is possible. I was trying to access the referrer of the document inside an iframe but it always disregard the hash(#) value.
Root Page(index.html) - (http://example.com/test#hashvalue)
Inside the Root Page, there is an iframe that gets the referrer. It has this piece of code
var referrer = document.referrer;
This returns http://example.com/test without the hash value. Is there a way to get the full url(with hash) as a referrer.
Note: that I dont have access to Root page. If I do, I can use postMessage but I don't. The iframe was just embedded(Lets call it as a widget of the root page).
Any url that contains the # character is a fragment url. The portion on the right of the # (that you want to access) is a fragment identifier i.e. a location within the page.
The browsers do not implement document.referrer to pass this identifier, this is in line with HTTP_REFERRER header passed to web pages.
If both of your iframes are from same domain i.e you are able to access parent.location from the child, then you can get the hash portion using parent.location.hash.
Hard luck otherwise
Related
I am writing a plugin for wordpress, and I provide a way for users to log in to my service, when they click on log in a popup opens with the service's website (which is on a different url than the wordpress blog).
So to avoid cross domain errors, I use postMessage This works great but the second argument of postmessage is the domain name of the website to send the data to.
I did a lot of research and all the examples seem to hardcode the domain name directly into it, but since it's a wordpress plugin, any domain can go there.
So I want to get the domain name of the parent window (the one who opened the popup).
I noticed that firefox manages to extract the url
when using the developer tools but I can't seem to manage to do it myself as almost all the properties are restricted.
So how can I get the url/domain name of the parent window for my popup?
The Same Origin Policy forbids JavaScript access to the location of a page on a different origin.
However, from the documentation you link to:
targetOrigin
Specifies what the origin of targetWindow must be for the event to be dispatched, either as the literal string "*" (indicating no preference) or as a URI.
If you want to limit message reading to a selection of origins (without making it public), then you could try to post a message to each in turn, or you could have the parent send its origin to the child (either through postMessage — although that has issues with timing, since you have to wait for the new page to load — or by simply passing it in the query string when requesting the page.
Pass it to your login page via query string added to the end of your service's website that opens your pop up.
Example:
var myservice = 'myservice.com?'+window.location.href;
Then from your site you get the parts you need and create a variable and substitute that for the hard coded address.
Getting the parts:
var prot = window.location.protocol;
var dom = window.location.host;
var path = window.location.pathname;
var qry = window.location.search;
document.getElementById("demo").innerHTML = dom + path + qry;
I am trying to access a cookie set on a subdomain (small.example.org) from the parent domain (example.org) and I would like to do this from a bit of Javascript within the page.
First of all I am setting a cookie for the domain small.example.org
document.cookie = "name=Mike; domain=small.example.org"
When I load small.example.org I can successfully see the cookie that I just set. When loading example.org I cannot see any cookies from small.example.org. Maybe not that surprising.
So I figured I need to make a request to the subdomain to include something onto the main domain, a script tag.
<script src="small.example.org/script.js"></script>
Now when I load example.org with the request to the script tag and have a look in the browser, I can see the cookie from small.example.org.
But when I try to access it from Javascript using document.cookie, I get nothing.
Is this the expected behavior? I thought you cannot access cookies from Javascript only if they had the HTTPOnly flag set.
Is there a way to go around this? The example above is very close to my actual use case scenario and unfortunately I cannot play too much with the architecture.
This is the expected behavior.
JavaScript can only access a cookie that if the domain of the cookie is either:
An exact match for the hostname of the current page
A substring of the hostname of the current page
example.org can't read cookies for small.example.org (although the reverse is not true).
Note that the Origin for JavaScript is determined by the URL of the HTML document the JS is running in, not by the URL that the JS was loaded from.
You can either:
Change the domain specified when you set the cookie
Dynamically generate the JS file on the server and insert the data using server-side programming (the browser will send the cookie in the HTTP request header when requesting the JS URL because the domains match).
I have an iframe in mysite.com/folder/file.php
The iframe is an html page from a subdomain and I want to block all referers except the current page it's embeded in (mysite.com/folder/file.php)
What's the best approach to this, using javascript ?
I tried to define rules in Nginx but the problem is the headers always show subdomain.com as the referer instead of showing current page.
The nginx approach could work. There is an nginx module which can filter by referer.
But the docs for that module state that the header is unreliable. It can be easily modified to show incorrect information by hackers.
But the DOM in the iframe'd html page should give you access to the 'parent' object.
That object could then be used to obtain information from the parent page like url or even some custom data you could set in the parent page.
I am not a javascript expert but I think this is the better approach.
I use JavaScript to insert the specific into the page. The problem is that it is necessery to load this iframe for the specific domain. I mean like in GoogleMaps, where you have to insert special key to be able load maps for your domain.
In few words I want to check where my script is linked from.
You can not get the parent property if your page is not on the same domain, the only solutions is to check the document referrer
var ref = document.referrer;
alert(ref);
Background: I have written a bookmarklet (JavaScript) that appends an iframe to the current page you are viewing. This iframe's src attribute is pointing to a form back on my (rails) application. I need to pass a key into the form (from the bookmarklet) by either modifying one of the values of the input fields or by passing the value as a parameter at the end of the url calling the form action.
I don't really see a way how to do the former, and the latter seems like a security catastrophe waiting to happen. I was wondering what the best practice would be here?
Appending a query string parameter to the URL seems reasonable, but you're correct - there are security implications. The value will appear in the user's browsing history and it'll be visible over unencrypted HTTP (but not HTTPS).
There's another Javascript-based way to do this that's not yet widely supported, but is worth considering - window.postMessage. It allows pages at designated domains to send and receive messages using a familiar event-based model. See https://developer.mozilla.org/en/DOM/window.postMessage.
This sounds fairly similar to the AJAX framework I made using iFrames. The easiest way is to have your bookmarklet build up a query string and put that on the iFrame's src. If you need to change anything, you should be able to set the iFrame's src to "#param=value" and have the page in the iFrame register the onhashchange event to deal with it (this would be how you could go about the former)
So your code could either be:
var iframe = document.createElement('iframe');
iframe.src = "http://example.com/mypage?param1=value1¶m2=value2";
document.body.appendChild(iframe);
and/or:
iframe.src = "#param1=value1";
// This in the iframe:
document.onhashchange = function() {
// parse location.hash and process form
}
A number of schemes pass secrets in the fragment portion of the URL and then, as then, early in the page load, store it and set the fragment to blank. I think webkeys do this.
On the webkeys page, see specifically
Putting the unguessable permission key in the fragment segment produces an https URL that looks like: https://www.example.com/app/#mhbqcmmva5ja3.