Our php-driven website has recently added ssl certificates to support the https protocol and we are having problems with IE6 through IE8 although our pages do not have resources called through http.
I have read this post : http://paulirish.com/2010/the-protocol-relative-url/
So, basicaly, I need to replace all the
background: url('/images/whatever.gif');
With :
background: url('//www.mydomain.com/images/whatever.gif');
I'm not quite a fan of using my domain name across several hundred css files to start with, but suppose I do : what would be the best practice to do so for my development, test and staging environments which are all on different subdomains than the production site. I would need to use dynamic representations of the domain name in the css files, most probably driven from some sort of config file, but how ?
You don't have to add your hostname to use protocol-relative URLs. The form you're already using is protocol-relative, because it doesn't specify a protocol.
Can you detail the problems you are having? Have you confirmed with a test that the URL with a domain name will solve your problem?
PS: If you have hundreds of CSS files, you'll probably be happier with a dynamic generation system anyway, but that's a separate matter.
The problems are popups in IE6, 7, 8 that say there is mixed content in the page (which should be http resources included in an https page). Chrome, FF4 and up and IE9 do not show those popups, and this is correct. There are no http included resources.
Several blog posts seem to point to background urls as the source of this problem. One of the posts (http://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx) has a comment from Eric Law at MSFT, who states :
The debugger reports that the following is the URL that is triggering
the prompt:
"about:/images/lightview/inner_slideshow_play.png"
Of course, that URL doesn't actually exist in your markup. It looks
like there's dynamic creation of an IFRAME and injection of content
into that frame. The default URL for an empty frame is about:blank,
which leads to the prompt.
and ...
Other quirks to be aware of: In IE6, we treat "about:blank" as
insecure content, as well as "javascript:" and "res:". In IE7, we
fixed the "about:blank" case, but we have not (yet) changed javascript
and res.
So the problem is known and confirmed by MSFT for their older browsers, which create an IFRAME and inject content that then generates the error.
Most workarounds I have stumbled upon point to using protocol-relative urls, like in the first url I showed. I'm not sure you can consider 'background: url('/images/whatever.gif');' as a protocol-less call, because of this infamous IE6 to 8 bug.
--Edit : Working on a solution. We have found this in our javascript files and it seems it has been the real problem from the beginning :
<input target="_blank"class="sub" type="button" style="background-image:url(../images/name.gif);">
Ok ! Got it.
By the way, if ever anybody runs accross the need to find exactly what problems they are having with IE6, IE7 or IE8 on https webpages that are incorrectly reported as containing mixed content, use this script : http://www.enhanceie.com/dl/scriptfreesetup.exe
So in the end it was the button I talked about in the last post. Changing it to an imported class, swapping background-image for just background and getting rid of the ../ at the beginning did the trick.
Thanks all for your help, I'll still flag an answer on Ned's input, since it was of some help.
Related
I've looked on SO and I can't seem to find a situation that helps me fix my issue.
I am using an iframe gadget on google sites to include a page from an intranet site of the company I work for into another intranet site I am working on right now. Like many I encounter the error 'X-Frame-Options' to 'sameorigin' making my iframe fail to work.
The thing is I only get this error when I am using Chrome. I tested the site with Firefox and it works just fine. The company has asked all employes to use Chrome only so it is rather annoying that it doesnt work for it.
I understand that this is probably due to the site being secured and refusing that people frame it, to avoid Clickjacking. However, it is rather important that I manage to frame the site into mine.
Is my only solution to go find the admin of the other intranet site so that he allows me to frame it? Or is there a work-around?
Just as information: the admin for the other site is not in the same country as me, making it difficult to reach out to him, this is mostly why I am trying to find a way around it.
If you're curious about browser compatibility for a specific feature, check CanIUse.com. See this question for a possible reason that your header isn't working in Firefox.
You should also note that x-frame-options is considered deprecated and is replaced by the frame-ancestors header. If you use both, x-frame-options will be ignored.
The answer to your question is: I hope not, because that would be a security hole. If the site owner doesn't want his stuff to be framed, it shouldn't be allowed in a frame.
If you need another site's content on your page, but iFrame isn't an option, you could try the answers given for this question.
I have found the issue and I feel pretty bad for missing it.
The domain of the page I wanted to include in my frame is company-name.com, whereas the domain for mine is company-name.com.sg.
This wasn't an issue on Firefox that seems to see both as the same domain. Whereas Chrome doesn't see them as the same, therefor I had to change my domain name to fix it.
So on Chrome always check that the domain is the exact same. Hope it helps anybody with the same issue.
Please Note: This question is not related directly to Server-side detection that a page is shown inside an IFrame, as I'm showing you an instance where it would appear that the guys at MDN (Mozilla Developer Network) are already detecting that content is being delivered to an iframe, although, if you read through this, I discuss the possibility that this isn't server-side related at all; it might be some sort of "rights" issue declared some how or in some way I don't know about. The point is to understand how something already existing works.
First of all, I do not desire to rip off MDN (Mozilla Developer Network) content as my own. I'm asking this because I'm truly puzzled by it. The guys at MDN seem to have pulled of a nice trick, and I'd like to know it, but maybe its simpler than I realized.
The code is only:
<iframe src="https://developer.mozilla.org/en-US/docs/HTML/HTML5"></iframe>
Take, for example, this fiddle:
http://jsfiddle.net/jfcox/D3UNZ/
Do you notice how there's no content in the iframe? There doesn't appear to be any content related to the request on the Chrome network tab.
I assure you, that'd work on a "normal" website, like example.org. see http://jsfiddle.net/jfcox/nPwcu/
So, I ask, what is it that they are doing to detect that a request is being made from an iframe?
Is there some Browser-Fu I don't know about? Oddly enough, that might be the case. From IE9.
To help protect the security of information you enter into this
website, the publisher of this content does not allow it to be
displayed in a frame.
Wow! Ok, so maybe it's not server-side, maybe it's all Browser-Fu. Even so, how does IE9 and these other browsers know what I don't know? What do I need to look up to learn about this?
I have my own suspicions, namely that there's some file at the root of the website like crossdomain.xml for flash that defines permissions about content usage or whatever, but I still wouldn't even know where to start if that's the case.
Turns out, it's a pretty simple copy protection. All you need to do is set a response header.
https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options
https://datatracker.ietf.org/doc/html/draft-ietf-websec-x-frame-options-00
Yes, "frame", instead of "iframe".
:eyeroll:
I suppose the name makes sense, considering the possibility somebody could still attempt to use old HTML 4 frame tags for whatever purpose, and I would expect most browser/DOM engines have baked-in support of frame tags given HTML history. Netscape created/supported frames as early as version 2.0 and iframe was a later, purely-Microsoft invention that found wide adoption, IIRC.
I implemented a script that monitors the iframe name as I understood was OK from various sources on the net. However it seems I must have gotten something wrong - I get
Error: Permission denied to access property 'name'
Source File: http://plungjan.name/test/testwindowname.html
Line: 16
Please visit http://plungjan.name/test/testwindowname.html
I would prefer just to fix my script and not use jQuery or DOJO or some other framework. Thanks
as I remember you must change iframe location to "about:blank" and after it you can access to its window.name property
Is it cross-domain communication you need here, or just the name of the window?
If the first one, take a look at easyXDM - it abstracts away all the hassle with XDM across browsers ranging from IE6 to Chrome10.
Take a look at this question:
Resizing an iframe based on content
Has a Cross Domain solution ... but you need to have access to both the servers to implement this solution.
This is a follow up to my previous question: Problem passing parameters via Iframe in IE. Which was never solved.
Here's the core of it:
I'm trying to execute an HTTP GET from
my website to another website that is
brought in via iframe.
On Firefox, you can see in the source
that the correct url is in the iframe
src along with it's correct
parameters-- and it works.
On IE, you can see in the source that
the correct url is in the iframe src
along with it's correct parameters--
and it doesn't work...
Is there something about IE that
doesn't let you pass parameters
through an iframe in the querystring?
I've tried refreshing the iframe in
IE, I've tried refreshing my page &
the iframe in IE, and I've tried
copying the url and re-pasting it into
the iframe src (forcing it to refresh
as if I just entered it into the
address bar for that iframe window).
Still no luck!
Anyone know why this is happening, or
have any suggestions to try to get
around this?
As for the code, all it's doing is creating
the src from the backend code on page
load and setting the src attribute
from the back end...
//Backend code to set src
mainIframe.Attributes["src"] = srcWeJustCreated;
//Front end iframe code
<iframe id="mainIframe" runat="server" />
I've made a temporary account for you to login and see exactly what I mean. That way you can use firebug or any of your other debugging techniques to figure out why this isn't working rather than having me try to explain what's going on.
EDIT: Changed the account credentials. Please use this one instead
Username: matt
Password: globalbuying
Please follow this link to get to the login page. One you login with the above credentials it will take you to the main backend page. Click the image on the left that says "Vacations", that will take to you a page with the iframe and will execute the Http Get from there.
If you need more details on what's going on in the behind code, etc., let me know and I'll post them.
Thanks,
Matt
After working my way through the HTTP requests with Fiddler2, comparing different browsers, I found that IE makes the request just fine, but fails to set any cookies in the iframe.
I also noticed that if I open that framed page by itself it does work. Even more so, after logging out again there, the iframed version works too. That's because it then already has a session cookie and the iframe no longer needs to set it.
It turns out that this is a known security restriction: IE blocks cookies in iframes. But this can be overcome with the use of the Platform for Privacy Preferences (P3P).
Here are a few links that should help you fix the problem. Starting off with another (answered) question on StackOverflow:
Cookie blocked/not saved in IFRAME in Internet Explorer
Privacy in Internet Explorer 6
IE Blocking iFrame Cookies
The example page you provided is working for me in IE8. The iframe is not as tall as in chrome, but it does have the correct page in it.
As an aside, please note that passing logon credentials via the query string is extremely unsecure and open to various exploits.
It seems that the ampersands in the iframe's URL are HTML-encoded (&).
I think that might cause IE to choke on identifying the param names. Does the problem still occur if you use plain ampersands in the URL?
If the encoding on the src attribute is happening implicitly, you might want to consider using a Literal control for testing purposes and set its Text property to the entire iframe tag to avoid any unwanted encoding.
Whenever we make changes to the CSS, it generally takes 24 hours to reflect those changes on my site. I have tried clearing the server cache and browser cache but it doesn't help too. Is there any other way to make the CSS changes reflect immediately after updation?
it happens in all the browsers... when i check it in the browser , i can access my css file with two paths eg : i store my css in folder named "Cssfolder" and my css name is say 135.css
So when i access the folder paths, Cssfolder/135.css & cssfolder/135.css, one of the path shows me latest css whereas other one shows me old css.Notice the "c" is captital in one path whereas small in other path.
Thanks.
I've found this to be a pretty common problem in a lot of my projects. I would suggest two things...
If it's just an app that you are working on you can use the CSS Cachebuster during development.
Following the idea behind the Cachebuster I have found that often adding the timestamp of the CSS file as a query string off of the CSS link will help in telling the browser that the file is different... something like... whatever.css?12212009035543
You might want to use a monitoring tool, like Live Http Headers for Firefox, to see the requests and responses to and from the server. This usually solves a lot of problems for me. Take a look at the "Expire" headers and conditional requests (like: "If-modified-since"). This said, take a look at server and client local times and timezones - it might be that they differ significantly and conditional GET requests "seem to be" handled correctly, because of future or otherwise mangled timestamps.
You can force to load the current css directly from the server with appending a random unique value to the url, like http://example.com/Cssfolder/135.css?983274928374 and http://example.com/cssfolder/134.css?08973249827. There's no way that this would ever get cached unless you use the same random value twice.
This way you learn where to look further for the solution to your problem: At the server, the ISP/a proxy or your browser.
You really need to see whether this is server side or client side. If the server is still serving the old CSS then clearly you've got no chance on the client side.
I've occasionally seen times where I've had to show the CSS in the browser, and then next time I've been to the real page, it's used that new CSS. Usually just hitting refresh does it.
Do you have any web caches like Akamai involved anywhere?
If you try to go to the CSS page from a computer which has never seen the old version, which version does it show?
EDIT: Changed answer to reflect edits in question.
I have been dealing with this issue in the past, and ended up writing a httpmodule to deal with it.
It's pretty simple, it just finds all script/css links in head tag (they now need to have runat=server) and appends the assembly version number to the link, in the same way as Tim K describes. This way im sure my clients always fetches the newest css/scripts when my app is updated in production, and never have to deal with this issue again.
Maybe Internet Service Provider cache, as in this case?
I was perplexed by this issue then someone said Ctrl+F5. Worked for me :)
When I am developing and I need to be sure that I am seeing changes as I work, I stick the css in the page ie
<style type="text/css">
/* your css */
</style>
Or you could constantly change the name of the css file itself, not very useful in a production environment, but perhaps okay while developing.
I know it doesn't solve the problem, but for developing it is okay.