gapi.auth.authorize callback is never called in IE10

[wonderfly]

From lukasz.p...@gmail.com on December 12, 2013 04:45:05

What steps will reproduce the problem? If possible, provide a live demo of the issue. 1. I use slightly modified example from the provided examples:

        window.handleGapiOnload = function(authResult) {
            function checkAuth() {                
                global.gapi.auth.authorize({
                    client_id   : config.googleDrive.clientId,
                    scope       : config.googleDrive.scopes
                }, authCb);
            }
        };

        // this callback is never called
        function authCb(authResult) {
            console.log('authCb', authResult);
        }

1. Authorization happens as it suppose to happen. However popup window is neve closed. It stays blank and the gapi.auth.authorize callback is never called.
2. Works like a charm in the latest Chrome (both regular and Canary) and Fiferox. What is the expected output? What do you see instead? I expect callback to be called. What version of the product are you using? On what operating system? Internet Explorer ver. 10.0.9200.16750
   Windows 7 Enterprise SP1 64bit Please provide any additional information below. Screenshot attached.

Attachment: blank_auth_popup.png

Original issue: http://code.google.com/p/google-api-javascript-client/issues/detail?id=120

[wonderfly]

From kth...@naver.com on March 30, 2014 19:52:41

So do I, Isn't any solution?

[wonderfly]

From SS2014...@gmail.com on April 17, 2014 00:40:16

I have the same problem. Is there anyone how solved this problem?

[wonderfly]

From benoit.p...@gmail.com on May 18, 2014 11:26:12

Hi, I think I found out the reason of this problem, unfortunately I cannot provide a workaround.

Actually troubles happen in the execution of javascript from 764632278-postmessage.js (the number may change depending on its version)
It is closely related to #74 (you should have a look at this issue entry too)
The blank page where we are stuck executes the postMessage.onLoad and if you follow closely the execution path then you will see that the pop closes if a function $ (nothing to do with jQuery's $ function) returns true. If it returns true then the execution path escapes before the closing logic in function F (see earlyReturn.jpg). The code for the $ function is
function(){try{return!!window.opener}catch(a){}return!0}

I have two computers with IE11 setup and for those two, the value of window.opener in the authentication popup is not the same. I tested it through the Js console. The one where I can reproduce this bug has window.opener set to null where it should be the "source" window which is the case with my second one.

Here are the version that fails and the version successful. Note that I do not have any trouble with Chrome.

Attachment: successfulIE.jpg failingIE.jpg earlyReturn.jpg

[wonderfly]

From SS2014...@gmail.com on May 21, 2014 03:31:48

I only have this Problem if i call the Website from "localhost".

[wonderfly]

From lukasz.p...@gmail.com on May 21, 2014 03:36:58

Hi OP here. So we narrowed our case to a problem with corporate proxy configuration. It worked like a charm outside corporate network. Once i t was I couldn't recall any more trouble wheter it was my localhost or any other server. This case is just strange.

BTW it worked on IE11 without any changes to proxy settings.

Sorry I know this is not much help :-(

[wonderfly]

From benoit.p...@gmail.com on May 21, 2014 03:40:04

I am investigating this right now and it seems that this problem is not a bug from IE or google api. Indeed, I removed the KB2953522 to fallback to IE11 11.0.7 and I am facing the same issue. Therefore, I guessed that its a config problem. Now, after some testing I a managed to make it work by changing manually the security options. I will post the precise required configuration when I will be sure which option is mandatory.

[wonderfly]

From benoit.p...@gmail.com on June 02, 2014 13:53:21

The culprit option is the "Enhanced protected mode" in IE. When unchecked we face the problem now known as "the blank popup". Fortunately, this option is checked for the internet. On the other hand, this is sometimes unchecked for local intranet. I guess, this is why most of us developers had this issue locally.
However, I believe the problem is not fully addressed as long as we would expect at least an error message like "the security options of your browser is not compatible with the google authentication process..."

Attachment: problematicOption.png

[vidyai]

Thanks for reaching out. This bug tracker is intended to report bugs in the Google API JavaScript Client. For support with Google Identity issues, please see https://developers.google.com/identity; if you still need help, ask a question on Stack Overflow under the google-oauth tag.