Browser blocked a frame with origin <remote site> from accessing a frame in my site - authentication

My predecessor at my workplace built a website (mahlerclean.com) for a client that allows job applicants to log onto another site (joblinkapply.com) via an iframe. The client has recently gotten complaints from applicants who are not able to log into the site via the iframe.
I am able to reproduce the issue in Safari. When I go to https://www.mahlerclean.com/career-center/job-openings it does not let me log into https://www.joblinkapply.com/company/6435 from there, and I see this message in the Safari web console:
Blocked a frame with origin "https://www.joblinkapply.com" from accessing a frame with origin "https://www.mahlerclean.com". Protocols, domains, and ports must match.
I have not been able to reproduce the issue in Firefox or Chrome though, and of course, if you navigate directly to https://www.joblinkapply.com/company/6435 (rather than through the iframe), it works fine in all browsers.
I control mahlerclean.com, but do not have any control over joblinkapply.com
My questions are:
Is there anything I can do to the site at mahlerclean.com that would
allow the iframe to joblinkapply.com to work on all browsers?
Why am I only seeing the issue in Safari? Are the other browsers likely to get more strict (i.e. behave like Safari) in the future?
Is it even reasonable to try to support logins to a remote site through an iframe, or should I tell the client to ditch the iframe, and just link out to https://www.joblinkapply.com/company/6435?

Related

Blocked a frame with origin "https://tpc.googlesyndication.com" from accessing a frame with origin "". Protocols, domains, and ports must match

I have doubleclick ads in my website.
When I open the website with my iPad (iOS version 9.3.5 Safari), I see the following error in the console:
Blocked a frame with origin "https://tpc.googlesyndication.com" from accessing a frame with origin "https://mywebsite.com". Protocols, domains, and ports must match.
** Replaced my website's url with "https://mywebsite.com"
Seems like this error is written to the log in an infinity loop. As you can see in the screenshot, the error was printed to the console 122.6K times.
In Chrome I didn't see these errors.
Why is it happening? Is there something I can do to fix this issue?
Thanks alot!
This happens because of a cross origin policy setup by Safari. You can simulate what it would be like to fix this by going to the Developer menu and selecting "Disable Cross-Origin Restrictions."
That will not solve it for your users though, and you have to include an exception for the domain when trusted by modifying the headers.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Access-Control-Allow-Origin

How can I determine the Reason IE is going into Compatibility View Mode and prevent it from happening?

Okay, here are the facts regarding our problem:
The web site we are working on is designed to use modern HTML5 features. This includes indexedDb.
We are using the following HTML right at the top of each page:
<!DOCTYPE html><html><head><meta http-equiv="X-UA-Compatible" content="IE=Edge"/>
All our users are using the same version of IE11.
We have 200+ active users who use the site, and for most of them, everything works just fine. The browser stays in "Edge" mode.
So far though, 3 of those users' browsers started opening the pages on the site in Compatibility View Mode instead of the default Edge mode. It was working for them fine previously.
If any other user goes to any page that those 3 users went to, they open fine (in Edge mode).
I created a super-simple diagnostic page devoid of CSS, HTML5 features, etc., when the users who are having the problems go to this page, it STILL going into compatibility view mode! It seems once the damage has been done, the browser wants to go into compatibility view mode for that domain regardless of the page content!
We've tried deleting Browsing History in the user's browser including cookies and website data... it does not fix the problem.
Restarting the PC does not work.
We do not have enough security to access any registry settings or directories where the browser stores its files.
So for starters, the question is, what steps can we take to figure out WHY their browsers when into compatibility mode in the first place. The only things I'm finding are vague error messages in the F12 console about using some feature or other improperly. No info about what feature or what error it caused.
And then, if that can be resolved, for users already in this mess, is there any viable steps we can take to get them so they see the site in Edge mode once again.
I'll be grateful for any help I can get on this. I am really stumped on this one!

Why Firefox 33 shows "is not fully secured" on the first load?

I am trying to setup my HTTPs website with Apache 2.2 and Firefox 33.
On the first load Firefox shows that warning.
But on the next page load (i.e. F5, another tab, etc until firefox restarts) everything on this URL is secure.
The page is just plain HTML, no javascripts, no images. I put robots.txt and favicon.ico into the /var/www/site/htdocs/ (I thought firefox loads them from http:// instead of https://). But this did not helped.
So, why firefox shows this warning on the first view after launch and don't does that later?
(I tried to ask this question on server fault, but don't have enough reputation to upload pictures)
UPD: Tools -> Web Development -> WebConsole says
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://mc.yandex.ru/webvisor/26570853?rn=493111185&page-url=http%3A%2F%2Fstart.calculate-linux.ru%2F&wmode=0&wv-type=0&wv-hit=372504783&wv-part=1&wv-check=34794&browser-info=z%3A240%3Ai%3A20141022210348%3Arqnl%3A1%3Ast%3A1413997437. This can be fixed by moving the resource to the same domain or enabling CORS. 26570853
Everything becomes ok, when I set about:blank as homepage.
But the question remains - how (in this scenario) scripts from previous page can affect next page?

Testing ssl HTTPS application locally with Coldfusion

I would like to test https related application on my local machine before pushing it to staging and production.
If I try to test on local system, the page just showing (in chrome it gets to the "This webpage has a redirect loop" page).
If any information could be provided that would assist me in setting this up / getting it working and testing, I would be extremely grateful . Thanks
This problem can have two angles whether this could be related to your specific browser or with your ColdFusion application:
First and foremost can you check it on Firefox or IE just to isolate if this is specific to Chrome. (As I have seen this to come on Chrome more than often)
if it works on Other Browsers:
probably Chrome is at fault. Go to settings (Options -> Under the Hood -> Content Settings -> Cookies -> Show cookies and other site data)
Enter your problem URL in search bar and it would list all related cookies.
Select "Remove all"
if it FAILS on other browsers as well:
Can you check with perhaps another test application?
Please check with following article by Ben Nadal --
http://www.bennadel.com/blog/1666-Ask-Ben-Enforcing-An-SSL-HTTPS-Connection-Based-On-Request.htm
If this persists, please add some more information, on how this has been set up.
Cheers,
Anjaneai
If I understand your questions you should be able to use a self signed certificate on your local dev box. Once you set this up you should be able to test your site in SSL mode.
Here is one quick tutorial.
http://weblogs.asp.net/scottgu/archive/2007/04/06/tip-trick-enabling-ssl-on-iis7-using-self-signed-certificates.aspx

YouTube embed request changed only for Safari –> chromeless player inoperable

I have a site with an embedded YouTube Flash (AS3) player, and it's no longer working in Safari.
Check out this fiddle, the code for which is merely:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer">
</object>
In Chrome, Firefox, and IE, the request to http://www.youtube.com/apiplayer returns normally (200). In Safari, the server returns a 303 to https://youtube.googleapis.com/apiplayer.
This player loads, but I am unable to interact with it in JavaScript. I assume that's because it's served over https — though I am explicitly requesting http — resulting in a mixed-mode security issue. Here's error I see when trying to do anything with the player (this is with the full chromeless player embed code):
>>> player.playVideo()
Error: Error calling method on NPObject.
If I change Safari's user agent to something else, or even just mangle the word "Safari", then the correct player is loaded. I also have no trouble loading the Vimeo and Viddler players (http://vimeo.com/moogaloop.swf and http://www.viddler.com/player/key).
I see this both in the stable Safari release and in the WebKit nightly. It also occurs with my extensions disabled and in Private Browsing mode.
I tried working around it by embedding http://youtube.googleapis.com, hoping that there would be no redirect and I'd get the player over http. But it still redirects to https, and it does so in all browsers.
I filed this YouTube API ticket last week, but there's been no response so far.
Seems like there's a playback issue with Safari and YouTube. There're multiple solutions suggested at MacRumours http://forums.macrumors.com/showthread.php?t=1098606, like switching to 32 bit browser, use non-HTML5 version, etc.
One that seems to work is below:
Select Safari > Preference > Privacy > Details
Search for Youtube
Delete the cookie called youtube-nocookie.com then click Done.
Restart Safari and try again.
The YT API bug report has been answered, and there is a workaround: appending the version to the URL:
<object type="application/x-shockwave-flash"
data="http://www.youtube.com/apiplayer?version=3">
</object>
Apparently when the version is not specified, they fall back to the AS2 player for Safari only. I'm not sure why that would force the switch to https, but regardless, this works.