I've got a web page (default.htm) that loads some custom dojo widgets. The widgets load fine when the entire url is typed:
http:/www.eg/default.htm
but when the site is hit as:
http:/www.eg
the widgets dont load.
when they load properly (when default.htm is specified) the console message is:
XHR finished loading:
GET "http://www.eg/Templates/WatershedMap.htm"
when they dont load the console message is:
OPTIONS http://templates/WatershedMap.htm net::ERR_NAME_NOT_RESOLVED
I'm running iis 7. Does anyone have an idea of how I might fix this?
Thanks
I suspect that in your dojoConf or data-dojo-conf, you are using location.pathname, is that correct? Or perhaps directly in your xhr request where WatershedMap.htm is loaded?
When you view the page with just http;//www.eg/, the location.pathname is just a slash "/". If then, for example, xhr tries to do this:
xhr(location.pathname + "/Templates/WatershedMap.html")...
... then the request will actually go to //Templates/WatershedMap.html.
That double slash means "protocol relative url". The browser will take the same protocol scheme (http/https) as the current page, and append whatever comes after the double slash.
In other words, that will actually try to make a cross domain request to http;//Templates , which triggers a preflight OPTIONS request.
However, when your page is loaded with http;//www.eg/foo/, the location.pathname will be "/something/something", and the request will go to http;//www.eg/foo/Templates/WatershedMap.htm.
You will have to share some more code if you need help to pinpoint the problem. Look through your code for location.pathname and see if you find anything that may be relevant.
Edit: based on your comment, your dojoConf has the following:
packages: [{
name: "Templates",
location: location.pathname.replace(/\/[^/]+$/, "") + "/Templates"
}]
The line with replace() in it takes the current page's path (for example /foo/bar.htm), and removes the last slash and everything after it, then appends "/Templates".
It is supposed to ensure that whenever you load something that starts with "Templates" (for example if you do dojo/text!Templates/Map.htm, it will look in the same directory on your server as the current page.
However, When you are on http;//www.eg/ , the pathname is simply a slash, and nothing is removed. So you end up with "//Templates". As mentioned earlier, this becomes a protocol relative url, with Templates as the hostname. Definitely not what you want!
On the other hand, when you are on http;//www.eg/default.htm, the pathname is /default.htm, so all of that is stripped away, and you're left with just "/Templates". This is what you want!
You could solve it by simply replacing the line with:
location: location.pathname.replace(/\/[^/]*$/, "") + "/Templates"
Only a single character difference (+ became *)! Now it will remove the single slash if you are viewing http;//www.eg/ as well.
In my opinion though, it's better to use an explicit path. If you know that /Templates will always be http;//www.eg/Templates, you may as well do:
location: "/Templates"
Related
I have an Html file containing the following code:
<script>
Object.defineProperty(document, "referrer", {get : function(){ return "myreferrer.com"; }});
//document.location="somelink.com";
</script>
From what I've read,maybe the thing I'm trying cannot be done,but I wanted to be sure.
I want to visit the site somelink.com but when my browser finishes the redirection to the location,the document.referrer value to be "myreferrer.com".
If I run the html with this format(document.location in comments)
the command in url --> javascript:alert(document.referrer) is the one I want.
But if I erase the comments and activate the document.location line,the above command will show up an empty document.referrer and not the one I want.
Can I achieve what I have in mind?
Some browser versions allowed you to customize the referer header using the approach of overriding the document.referer property in javascript, but that doesn't appear to be reliable. Even if some browsers still allow that, there's no guarantee it would work in future versions.
If you need a workaround, you could link to the desired referrer domain and serve up an intermediate page that performs the navigation to the final destination URL via an HTML form submission. That should preserve that intermediate page as the referrer.
Within the context of a browser extension however, you can alter the headers via onBeforeSendHeaders
So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:
My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.
Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.
What I've tried to do so far:
Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.
Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.
You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: http://pastebin.com/sKQTvgY2 ... along with a sample of the ISP's injection.
Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to accomplish that. I believe it'd fix the iframe-breaking problem.
I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?
Actually now I have a solution:
The ISP proxy react on the Accept: header that the browser sends.
So this is the default for firefox:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Now we are going to change this default:
And set it to: Accept: */*
Here is how to setup header hacker for google chrome
Set the title to anything you like:NO IFRAME
Append/replace select replace with
String */*
And Match string to .* and then click add.
In the permanent header switches
Set domain to .* and select the rule you just created
PS: changing it in the firefox settings does not work 100% because some request like ajax seem to bypass it so a plugin is the only way as it literally intercepts every outgoing browser request
That's it no more iframes!!!
Hope this helps!
UPDATE: Use DNSCrypt is the best solution 😁
OLD ANSWER
Im using this method
Find resource that contain iframe code (use chrome dev tool)
Block the url with proxy or host file
I'm using linux, so i edited my hosts file on
/etc/hosts
Example :
127.0.0.1 ibnads.xl.co.id
I have an AJAX post that retrieves data from the server and either replaces part of the page or in some cases the full page. This is controlled by a javascript fullRefresh parameter. The problem is the refresh code works find in Firefox but causes a Permission Denied error in the bowels of JQuery after it runs in IE although it would appear to actually replace the page contents successfully.
IE version 11.0.9600.16659
JQuery version 1.8.2
Error message
Unhandled exception at line 2843, column 3 in http://localhost:62761/Scripts/jquery-1.8.2.js
0x800a0046 - JavaScript runtime error: Permission denied
My code is
function RefreshScreenContent(formActionUrl, formHTML, fullRefresh) {
fullRefresh = (typeof fullRefresh === "undefined") ? false : fullRefresh;
if (fullRefresh) {
document.write(formHTML);
document.close();
}
else {
$("#content-parent").html(formHTML);
}
}
The partial refreshes work fine but the full refreshes are the problem. I have tried hardcoding the document.write call to write a well formed simple html page rather than formHTML in case that was somehow the problem but even a simple single word page causes the error.
The actual error occurs a some point later with a callback inside JQuery.
The AJAX post to the server is in the same application i.e. is not a cross domain request. I have seen posts online talking aboue cross domain stuff that is not applicable here.
Can anyone tell me why this is happening and how to stop it? Is there an alternative IE way of replacing the page contents?
Your code is fine (at least at first glance). My guess is that you make the call in such a way, that it is interpreted as cross-domain.
I would suggest checking:
http vs https (most common)
the destination port
the root url
maybe the "destination" page makes some requests of its own, check to be on same domain
The reason why IE may be the only one with the problem is that it has higher security demanding by default that other browsers (check advanced security settings - can't remember where they are put in menu) so it interprets requests in a more "paranoid" manor.
I repeat, what I said is just a guess, based on cases I've been put into.
In the end I used the approach here to replace the body tag in the pgae with the one in the markup the AJAX receives back https://stackoverflow.com/a/7839921/463967
I would have preferred to replace all content not just the body but I can always adapt later to include the header etc as body is enough for my uses right now. This works in IE and Firefox.
In my https application I am loading some images. If Img src is not available I will show the default image - I got this js that will do the job for IE also:
$(document).ready(function(){
$("img").each(function(index) {
$(this).error(function() {
this.src = "/shared/ts/web/images/missing_img.gif";
});
$(this).attr("src", $(this).attr("src"));
});
});
It works great with IE10, but with IE8 I have a security warning:
Do you want to view only the webpage content that was delivered securely?
If I click on yes -> I cannot see the missing_img.gif, if I click on no everything is ok.
Can you tell me why am I getting this warning and what can I do to remove it?
I don't want to change the client default IE8 settings.
From the looks of it you are not delivering that particuar image via https. Any resource that is not delivered by https can potentially be modified or read by an attacker whilst in transit. This will throw errors in some browsers, whilst others (such as Chrome) will 'cross out' your 'https' bit in the url to show that not all elements are secure.
To fix it, make sure that all the resources you deliver are via https. So in this case you might want to force it by doing
this.src = "https://mysite.com/shared/ts/web/images/missing_img.gif";
I'm not entirely sure why this isn't automatically using https. Maybe someone else can enlighten you on that one.
It's because your image (because you didn't specify https:// as protocol) gets the http:// protocol..
Since this on your secure site, it'll try to load "http://domain.com/shared/ts/web/images/missing_img.gif" and that's "not secure content on a secure site"
I think you can fix this by either make the path absolute (include the entire part of it including https://your-domain.com), or use "//" (double slashes) and omit the http(s): part, so it'll take the same protocol as the site (https when the site is secure, http otherwise).
I have been asked to build a tabbed section on pages that have RESTful URLs without a trailing slash (.NET MVC), for example http://myhost/books/the-amber-spyglass
For the tabbed sections to be a bit more user friendly I want them to remember which tab was open on each page as the user moves around, so that if they return to a book they were previously on the same tab remains opened. This is achieved by setting a cookie named "tab" with value set to the tabid and path set to the page they are on (so it doesn't affect tabs on other pages). So far pretty basic stuff you'd think, and it does work quite nicely too.
Enter Internet Explorer.
In IE it turns out a cookie with path /books/the-amber-spyglass will NOT match the above URL and consequently won't get set properly. If I add a trailing slash so the path is /books/the-amber-spyglass/ instead it works fine - but I cannot change our URL schema, and even if I could "the-amber-spyglass" is a resource, NOT a folder.
Does anyone have a recommended solution to this, surely exceedingly common, problem?
Many thanks in advance,
JS
See http://blogs.msdn.com/ieinternals/archive/2009/08/20/WinINET-IE-Cookie-Internals-FAQ.aspx
Due to an obscure bug in the
underlying WinINET InternetGetCookie
implementation, IE’s document.cookie
will not return a cookie if it was set
with a path attribute containing a
filename.
For instance, if a page sets a cookie
on itself like so:
Set-Cookie:
HTTPSet-PathCookie=PASS;path=/check.htm
…the cookie will be sent with HTTP
requests but will not appear in the
document.cookie collection.