Window.open() reference blocked in IE11 - javascript

I'm implementing Twitter OAuth sign in in my web app. I'm doing this in a separate window popup, since I read that IFrame is no longer allowed in OAuth. So, as soon I open a new window on Twitter domain, IE sets twitterWindow reference to null. This is due to IE's aggressive Internet zone security settings, which I can't ask from users to disable.
var twitterWindow = window.open(twitterUrl, "TwitterLoginPopup", "width=600, height=600");
When Twitter redirects window back to my domain (after successful or failed authentication), I can see window again and handle the results. But use-case that troubles me is when user closes the window manually and since I don't have its reference, I can't handle that closure.
I tried to implement postMessage() communication between application and window, but that's also impossible without window reference. Does anybody have any workaround for this or idea for different implementation of the OAuth? Thanks in advance.

Related

IE11 does not send cookies to server after opening a new window from a nested frameset

Summary: A client has a problem when launching a new browser window using IE11, where no cookies are sent to the new window. I am unable to reproduce the problem locally. It will work if they use FireFox or a different LMS.
Detail: The client is running a LMS and imports a SCORM package from us which opens a frameset to our site - note the clients LMS and our content are on different domains.
As part of the content the user clicks on a link and a new window is opened using window.open(url, "_blank"...) or an anchor tag with a _blank target, the url is always on the same domain as the page that launched it.
When the new window is opened no cookies from the previous page are sent.
I can see that additional requests on the previous page maintain the cookies and new cookies set within the new window are sent back and forth.
If the client uses FireFox to launch the LMS or if the client launches the content from ScormCloud within IE the problem does not occur and the new window launches with all cookies intact.
I have attempted to replicate their environment locally (same OS, IE and configuration settings) but I am unable to reproduce the problem, or work out how to work around the problem.
Any ideas on what the problem may be, how to reproduce it or even work around it?

Why IE8 blocking a pop-up window which appears in IE7?

I am working on a client server application,in which we open client on our pc by URL:http:\[ip of server]:[port no].
My application start by using the URL mentioned in IE, and one pop-up comes in which we perform every action of the apllication and original window we can close as they are only for starting. One of my customer is using IE8 and he is facing a problem in which after clicking on save to bookmark the pop-up is not coming and hence not able to save. In IE7 pop-up as an another window is coming and giving the option to save.
What is blocking the pop-up? Thanks in Advance...
For popups the same goes as for spam email - as the popup developers get smarter, so do the popup blocker developers. As such it makes sense that newer browser versions are stricter in the rules they evaluate to determine when a popup needs to be blocked.
All modern browsers follow the same rules, that all boil down to "popups are only allowed if the user directly initiated them". This means that they guard execution paths, and every call to window.open is caught by the popup blocker unless it can be directly traced to a user action. And as popup developers invented more inventive ways to make a browser think the user initiated it, popup blockers got more inventive in detecting them.
A quite plausible explanation is also that you are developing on a LAN, where IE applies lower security settings by default, allowing more user popups automatically. We cannot see that from your post though.

On IE9, Win 7 window.open() returns null instead of reference of the opened window

I am trying something like below,
var myWindow = null;
if(!myWindow || myWindow.closed)
{
myWindow = window.open(url, windowId);
}
else
{
myWindow.focus();
}
All browsers return the window ref for window.open(), but IE 9 returns NULL. Does anybody have more information on why null is returned or possibly a workaround solution for IE9?
window.open returns a NULL reference object if Enable Protected Mode is checked under Internet Options->Security->Security Level for this zone and the ZONE is different i.e. in my case local file opening a popup from Intranet.
window.open returns a reference object even if Enable Protected Mode is checked when mysite.com opens someothersite.com in popup window i.e. Internet->Internet
Out of curiosity, what's your windowId? Does it have a space in it?
Because, apparently IE9 will fail if there's a space in the window title.
Actually in my case, I was getting window.open reference null if I'm opening localhost or intranet site URL. If my popup contains any internet site url then I'm getting window object in reference.
I did following to resolve this:
Open IE > Tools > Internet Options
Go to Security Tab
Enable Protected Mode by clicking the checkbox
Restart IE
Now, it started giving me window object reference for popup window opened with Intranet Sites.
Also, it could be the URL problem where it is secure or added in trusted sites zone. If you can provide the URL it will help.
Hope this helps.
We had this problem with our app. We are using external uploads using Dropbox and it was not working.
This is how we fixed it. Summarizing the different reads and solutions. Please let me know if any part is not correct or does not make sense.
Root Cause:
Starting from IE11, Windows has started assigning the security levels to the applications at the time of startup. Low-Security window and High-security window. Also starting IE11, when new popup opens, it is not a sub-window of the main browser window. Instead, it is a whole new IE11 instance with different security level assigned to it. Usually, the external upload mechanism works using the cross window messaging feature of JavaScript. If that does not work, external uploads do not work. As per windows security standards, a low-security window cannot send a message to the high-security window. Taking a step back and looking at our windows machine, they are shipped by our Internal team. By the default, all our domain web applications are added to trusted sites in our windows machines. But external upload links like Dropbox is not added to the trusted sites. So when you open Our App in IE11, windows automatically marks IE11 window as High-security window. Now, when you try to upload a design file through Dropbox because Dropbox is not trusted site, the new popup that gets created is a new IE11 instance with low-security level. Due to this, after the Dropbox window opened, it loses connection with the parent window that is Our App. This is causing the issue with External uploads
Fix:
Either add both yoursite.com and dropbox.com to trusted sites in IE11 through Internet Options > Security > Trusted Sites or remove them both.
Enable Protected Mode in IE11 by marking Enable Protected Mode in IE11 through Internet Options > Security > Enable Protected Mode and then restart the browser.
This means it is not a real issue for our Customers. If it's not working for them, it is either due to the reason, either of the sites is added to the trusted sites list but not both.

Chrome-only cross-domain scripting errs in Facebook iFrame App upon FB.Login(..)

In Google Chrome (I'm on 9.0.597.98) my Facebook iFrame app using Graph API/Javascript SDK tends to always throw the following two JavaScript errors (see below) based on cross-domain scripting, but only on one page of the app.
It goes into an endless retry loop on the second message. After leaving it overnight, it reported a half million retries by this morning!
The FB call being used is for login:
FB.login(function(response) {
if (response.session) {
// user successfully logged in
} else {
// user cancelled login
}
});
In Firefox and IE9 I do not get these errors. It's specific to Chrome (maybe WebKit).
What's odd is I have a second page in the app that uses FB.Login and it works in Chrome in addition to the other browsers.
I read somewhere that Safari has more stringent requirements on cross domain scripting - it and Chrome share the same code base.
Domains, protocols and ports must match (error message) I believe is actually satisfied because I have another page that works with the FB.Login call The only other difference I see between these two messages is the postmessage query argument has a different value for each (bolded in the messages). However there is only one iFrame that constitutes a Facebook app so I wonder why two different values might be used one after the other. I don't mean to lead answers to focus on this item, but I did want to point it out.
Suggestions are welcome as to what I might try to resolve this errors.
Chrome JavaScript Console Messages:
Message 1: Unsafe JavaScript attempt to access frame with URL
https://www.facebook.com/dialog/permissions.request?api_key=168297653202478&app_id=168297653202478&display=popup&fbconnect=0&locale=en_US&method=permissions.request&next=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%23cb%3Df3d15633dc%26origin%3Dhttp%253A%252F%252Fsubdomain.example.com%252Ff22a8befa%26relation%3Dopener%26transport%3D postmessage %26frame%3D f111baf6f4 %26result%3D%2522xxRESULTTOKENxx%2522&perms=publish_stream%2Coffline_access&return_session=1&sdk=joey&session_version=3 from frame with URL http://subdomain.example.com/colonversationmap/Admin.TestPage.aspx?signed_request=871miFgH_-o05POnx20387XHd2YlArKLU6qUv8VkxY4.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImlzc3VlZF9hdCI6MTI5ODQyMDEwMSwidXNlciI6eyJjb3VudHJ5IjoiY2EiLCJsb2NhbGUiOiJlbl9VUyIsImFnZSI6eyJtaW4iOjIxfX19. Domains, protocols and ports must match.
Message 2: Unsafe JavaScript attempt to access frame with URL
https://www.facebook.com/dialog/permissions.request?api_key=168297653202478&app_id=168297653202478&display=popup&fbconnect=0&locale=en_US&method=permissions.request&next=http%3A%2F%2Fstatic.ak.fbcdn.net%2Fconnect%2Fxd_proxy.php%23cb%3Df304d46e08%26origin%3Dhttp%253A%252F%252Fsubdomain.example.com%252Ff23ce8203%26relation%3Dopener%26transport%3D postmessage %26frame%3D fcd3637bc %26result%3D%2522xxRESULTTOKENxx%2522&perms=publish_stream%2Coffline_access&return_session=1&sdk=joey&session_version=3 from frame with URL http://subdomain.example.com/colonversationmap/Admin.TestPage.aspx?signed_request=871miFgH_-o05POnx20387XHd2YlArKLU6qUv8VkxY4.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImlzc3VlZF9hdCI6MTI5ODQyMDEwMSwidXNlciI6eyJjb3VudHJ5IjoiY2EiLCJsb2NhbGUiOiJlbl9VUyIsImFnZSI6eyJtaW4iOjIxfX19. Domains, protocols and ports must match.
I also ran into an issue where the getLoginStatus() was not being called in Chrome. I tried calling it on page load and after a user-initiated action with no success.
It turned out that it was not a cross-domain issue. The call was being blocked by the Un-Passwordise extension in Chrome. As soon as I disabled the extension, it worked perfectly, even on page load.
More info about this issue here: FB.getLoginStatus never fires the callback function in Facebook's JavaScript SDK
For my case, it turned out that Chrome complained whenever I called the Facebook JavaScript API's FB.login(..) method immediately upon Page or DOM load.
To circumvent this problem in Chrome I put a button on the page that the user must click to initiate the login script. That works in Chrome. It's a workaround but good enough for me for now.
note: For the secondary page that I mentioned in my question that works, it already was set up for user-initiated login prompt.
Adding a channel file may help this problem. See the Facebook Javascript API documentation:
https://developers.facebook.com/docs/reference/javascript/
I had this problem on my site, but turned out I was using old version of FB.login.
From Facebook FB.login page:
As of December 13th, 2011, the JavaScript SDK now only supports OAuth 2.0 for authentication. The ability to enable OAuth 2.0 in the JS SDK was first introduced in July. All apps were given until October 1, 2011 to test and migrate. With this change, please ensure that you replaced response.session with response.authResponse. To ask for permissions, you must use scope instead of perms. Read more about the specific changes here.

Detecting when a Cross-Domain Popup Window Closes

I have a JavaScript application that lives on say domainA.com. In order to authenticate a user and set cookies, it opens a popup window on domainB.com. (this is similar to Twitter's #anywhere).
How do detect when the popup on domainB.com closes and call a function in the JavaScript that opened it on domainA.com?
I've tried various methods like window.opener, window.unload, etc, but run into cross domain limitations.
window.postMessage will help you on browsers that support it...
https://developer.mozilla.org/en/DOM/window.postMessage

Categories