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.
Related
This problem exists for all pages on this site. The meta tags appear correct but whether you use the share link on the site, or try to share direct on FB, the image, title and description are not used.
There must be a legitimate issue as the Sharing Debugger also shows an empty/plain sharing dialog. But the Facebook share debugger isn’t given me any helpful info. It sometimes shows a 302, which I don’t understand as there is no redirect on the site. Refreshing the scrape sometimes shows an error Unknown Image Error, which also doesn’t seem to be a legitimate issue.
Almost always the Facebook share debugger shows a 302 the first time and then follows with other unhelpful errors.
Maybe a DNS issue, weird that it would be site wide.
Example Links:
[http://pikespeakharleyownersgroup.com/group-riding-pphog-405/][1]
[http://pikespeakharleyownersgroup.com/tell-tires-toast/][2]
[http://pikespeakharleyownersgroup.com/30th-annual-high-country-toy-run/][1]
Any and all help is very appreciated.
Try debugging your page URL on below link:
https://developers.facebook.com/tools/debug/
Once you scan your URL, on the link I provided, you will see "Warnings That Should Be Fixed" section. Try resolving warnings mentioned in that section.
Hope this will help you!
Recently ran into some trouble with Google DFP that I'm hoping others have had.
We have a site that's served via SSL and it contains some Google DFP ad tags. Google DFP's debugging console shows no errors in the tags or our implementation of them. (i.e. the tags themselves are fine)
However, the ads are getting served via different methods. Some of the iframes get served as FriendlyFrames and some get served as SafeFrames. The SafeFrame ads appear correctly. The FriendlyFrame ads don't show up.
It appears that the FriendlyFrame ads are running afoul of some sort of browser security measure (likely because the pages are served via SSL).
I looked into this in the DFP docs but haven't found anything that explains how to solve the issue. There is a setForceSafeFrame method available that I've tried to use but it doesn't actually seem to do anything when I try to use it:
https://developers.google.com/doubleclick-gpt/reference#googletag.PassbackSlot_setForceSafeFrame
I've setup a test page demonstrating the issue here:
https://methnen.com/ad-test
There should be 5 separate ads on the page. If you get all of them refresh the page until you get at least one ad that doesn't show. The broken ads are being served as a FriendlyFrames.
Really hoping someone knows what the heck is going on.
FYI and possibly helpful for anyone else who might run into this at a later date:
Turns out the Ad Ops person hadn't set things up on their end to have enough inventory to fill all of the slots and there was nothing wrong with the tagging at all. The empty FriendlyFrames are apparently what DFP serves up when it decides it doesn't have anything to fill a given slot.
Try to force render all ads in SafeFrame
googletag.pubads().setForceSafeFrame(true);
More about it here https://developers.google.com/doubleclick-gpt/reference#googletag.PassbackSlot_setForceSafeFrame
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 am using the code to place a linkedIn Follow button (generated here https://developer.linkedin.com/plugins/follow-company) on this page, http://new.janeirodigital.com (view Client Testimonials section). However, the buttons sometimes show up and sometimes don't.
I have read a little bit of cross domains issues that may cause this, but I am not able to find a workaround to fix this. If you visit that page in Chrome and see the errors console, you'll see a couple of errors like regarding the linked in button, like:
Unsafe Javascript attempt to access frame with URL mysite.com from frame with URL http://platform.linkedin.com/js/....Domains, protocols and ports must match.
Has anybody experienced this problem before?
Any help appreciated
Daniel
The messages you are seeing in the developer console in Chrome are unrelated to your problem. They are an artifact of the cross-domain communication and as you'll notice, you see them for Facebook and Twitter as well on the same page.
That said, viewing your page I am also seeing intermittent 403s for some of the backend calls that the FollowCompany plugin is making. I have alerted our NOC to the issue and they should be investigating now.
Reviewing your page, it seems you have done everything necessary and are set, so once we fix the operational issue you should be good to go.
My apologies for any inconvenience!
-Jeremy
I just found that this is happening when there are more than one follow button on the page, if you delete the first one and the second shows without problems but the others have the same problem...
Hope this could help your team Jeremy!!
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.