I am using React and I am getting the document referrer using
document.referrer
However when I am directed to my url from google.com, I am just getting the domain in document.referrer instead of something like this: https://www.google.com/search?q=fb&rlz=1C1CHBF_enIN850IN850&oq=fb&aqs=chrome.0.69i59j46i199i291i433j0i131i433l2j0i395j69i60l3.1007j1j9&sourceid=chrome&ie=UTF-8.
Is there someway I can get the entire URL including pathname and query string? Thanks in advance.
Websites can set a Referrer-Policy. If they don't then, as of version 85, Chrome defaults to strict-origin-when-cross-origin. (Other browsers will have their own defaults, but Chrome's marketshare makes it worth highlighting)
This means that the referrer information will include only the origin and not the full URL.
This is a feature designed to protect the user's privacy.
There is no way around it unless you control the site that controls the link (in your example: www.google.com).
Related
I want my extension to change the document.referrer of certain webpages, but searching for this leads to documentation on how to change the Referrer in the HTTP request headers.
Is there any way to use an extension to change document.referrer, preferably before the javascript(s) of a webpage loads?
Currently I refresh pages where I want the document.referrer altered with window.location.replace(window.location.href), but this generates a noticeable flicker, and only can change the referrer to the current page.
override.js:
Object.defineProperty(Document.prototype, 'referrer', {
get() {
return 'foo';
},
});
This should be put in page context at document_start, there are several methods.
For ManifestV3 the most reliable method is registerContentScripts: example. Specify the correct pattern in matches and optionally add allFrames: true; matchOriginAsFallback: true if the site uses frames.
Note that due to a bug in Chrome the sites can extract the original getter and call it on the main document to get the real referrer. The workarounds are mentioned in the report and aren't simple.
I am developing a web page that needs to display, in an iframe, a report served by another company's SharePoint server. They are fine with this.
The page we're trying to render in the iframe is giving us X-Frame-Options: SAMEORIGIN which causes the browser (at least IE8) to refuse to render the content in a frame.
First, is this something they can control or is it something SharePoint just does by default? If I ask them to turn this off, could they even do it?
Second, can I do something to tell the browser to ignore this http header and just render the frame?
If the 2nd company is happy for you to access their content in an IFrame then they need to take the restriction off - they can do this fairly easily in the IIS config.
There's nothing you can do to circumvent it and anything that does work should get patched quickly in a security hotfix. You can't tell the browser to just render the frame if the source content header says not allowed in frames. That would make it easier for session hijacking.
If the content is GET only you don't post data back then you could get the page server side and proxy the content without the header, but then any post back should get invalidated.
UPDATE: 2019-12-30
It seem that this tool is no longer working! [Request for update!]
UPDATE 2019-01-06: You can bypass X-Frame-Options in an <iframe> using my X-Frame-Bypass Web Component. It extends the IFrame element by using multiple CORS proxies and it was tested in the latest Firefox and Chrome.
You can use it as follows:
(Optional) Include the Custom Elements with Built-in Extends polyfill for Safari:
<script src="https://unpkg.com/#ungap/custom-elements-builtin"></script>
Include the X-Frame-Bypass JS module:
<script type="module" src="x-frame-bypass.js"></script>
Insert the X-Frame-Bypass Custom Element:
<iframe is="x-frame-bypass" src="https://example.org/"></iframe>
The X-Frame-Options header is a security feature enforced at the browser level.
If you have control over your user base (IT dept for corp app), you could try something like a greasemonkey script (if you can a) deploy greasemonkey across everyone and b) deploy your script in a shared way)...
Alternatively, you can proxy their result. Create an endpoint on your server, and have that endpoint open a connection to the target endpoint, and simply funnel traffic backwards.
Yes Fiddler is an option for me:
Open Fiddler menu > Rules > Customize Rules (this effectively edits CustomRules.js).
Find the function OnBeforeResponse
Add the following lines:
oSession.oResponse.headers.Remove("X-Frame-Options");
oSession.oResponse.headers.Add("Access-Control-Allow-Origin", "*");
Remember to save the script!
As for second question - you can use Fiddler filters to set response X-Frame-Options header manually to something like ALLOW-FROM *. But, of course, this trick will work only for you - other users still won't be able to see iframe content(if they not do the same).
When I was examining Google+, I'm surprized when I see usage of URLs. Google profile URLs change without refresing page. For example this is a photos tab URL: https://plus.google.com/104560124403688998123/photos When you click Videos tab, URL exactly goes to https://plus.google.com/104560124403688998123/videos without refreshing page. How Google coders success this?
Have a look at the history object https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
Especially history.pushState and history.replaceState
(Should mention that this only works in modern browsers, for old ones use hashes).
This is about HTML 5. take a look at "onpopstate event". For further information go to the link. http://spoiledmilk.dk/blog/html5-changing-the-browser-url-without-refreshing-page
You could try using a pushState.
You can change the URL to another URL within the same domain, but can not change the domain for security reasons.In Javascript, you can use.
window.history.pushState(“object or string”, “Title”, “/new-url”);
Object and string is your domain ex. www.google.co.in
title you can give whats you want.
and lastly you place new url ex. 'webhp?source=search_app'
ex. window.history.pushState(“www.google.co.in”, “Google”, “/webhp?source=search_app”);
You could try using a hash. This is not how google does it, but it doesn't force a refresh. In Javascript, you can use
parent.location.hash = "Text";
so that the URL will be http://yoursite.com/yourpage#text
Edit: This seems to be new to Google+. GMail uses a hash like
https://mail.google.com/mail/u/1/#inbox/130f48da33c5330
I am trying to integrate with the FireShot API to given a URL, grab HTML of another web page into a div then take a screenshot of it.
Some things I will need to do after getting the HTML
grab <link> & <script> from <head>
grab <body> into <div>
But 1st, it seems when I try to do a
$.get("http://google.com", function(data) { ... });
I get a 200 in firebug colored red. I think it has to do with sites not allowing you to grab their page with JS? Then is opening a window the best I can do? But how might I control the other page with jQuery or call fsapi on that page?
UPDATE
I tried to do something like below to do something when the new window is ready, but FireBug says "Permission denied to access property 'document'"
w = window.open($url.val());
setTimeout(function() { // if I dont do this, I always get about:blank, is there a better way around this?
$(w.document).ready(function() {
console.log(w.document.body);
});
}, 1000);
I believe the cross-site security setup within Javascript is basically blocking this. You'd likely have to proxy the content through your own domain.
There are a couple other options I think for break the cross-site security constraints, but I'm not sure I'd promote them.
If the "another page" locates within the same domain of your hosting page, yes, you can. Please refer to jQuery's $().load() API.
Otherwise, you're disallowed to do so by the browser's Cross-Site Security Policy. At this moment, you can choose to use iFrame instead of DIV.
Some jQuery plugins, e.g. thickbox provides ability to load pages to appropriate container automatically.
Unless I am correct, I do not believe you can AJAX a page cross domain (e.g. from domain1.com to domain2.com). To get around this, you can have a PHP "proxy" script that does the "getting" of the page and then pass it to JS.
For example, in JS you would get() http://mydomain.com/get/?domain=http://google.com and then do what you need to do!
How to automatically replace url in browser address bar with JavaScript
from company.com/en/services/
to company.com/en/#services
?
Example: when I type in browser address bar url company.com/en/services/ and click 'Go', it will be automatically seen company.com/en/#services
Is there any way to replace real url /services/ with hash url /#services without browser refresh and no redirecting? Does jQuery has some solution for that?
You can't change the URL with Javascript for the current page. You can only change the hash like this (without causing a refresh):
window.location.hash = '#services';
So when you're at the page company.com/en/ and then click something, you could then set the window.location.hash. For example, it could be changed to company.com/en/#anything_you_set. The only other way is to do what Pekka suggested and reload the page.
If you want them to type the url and have it change to the hash, you're going to have to look up URL Rewriting (at least for ASP.NET and IIS). If you're on IIS7, you can use the URL Rewrite Module.
If you're on apache, you can read this URL rewrite tutorial.
You could do something like this:
$(document).ready(function() {
window.document.location.href = 'company.com/en/#services'
});
I'd go with:
<script>
document.replace("/en/#services");
</script>
<meta http-equiv="refresh" content="0;url=/en/#services" />
on /en/services/
Document.replace(url) will have the browser load the new page, and the old one won't be in the history, so when the user hits back, they won't get stuck in loop. The meta catches people without JS.
I don't think that you can't reliably do this with a server-side redirect, as many browsers (and the HTTP spec) consider the hash client-side only, and so it doesn't survive the redirect.
I found the solution in http://www.asual.com/jquery/address/.