1

I was following the accepted answer for this question How do I get around window.opener cross-domain security to solve my problem. The code works great but fails at one use case where instead of the pop up window url getting changed from some other domain to your own domain, it simply redirects on its own domain just like sometime if you try to authenticate a third paty app on facebook or some other social network, it simply redirects on its own as you have already authenticated earlier. How can we handle this scenario in the following code:

<!DOCTYPE html>
<head>
<title>main</title>
<meta http-equiv="X-UA-Compatible" content="IE=edge"/>
<script>
window.addEventListener("message", function(ev) {
    if (ev.data.message === "deliverResult") {
        alert("result: " + ev.data.result);
        ev.source.close();
    }
});

function Go() {
    var child = window.open("child.html", "_blank", "height=200,width=200");

    var leftDomain = false;
    var interval = setInterval(function() {
        try {
            if (child.document.domain === document.domain)
            {
                if (leftDomain && child.document.readyState === "complete")
                {
                    // we're here when the child window returned to our domain
                    clearInterval(interval);
                    alert("returned: " + child.document.URL);
                    child.postMessage({ message: "requestResult" }, "*");
                }
            }
            else {
                // this code should never be reached, 
                // as the x-site security check throws
                // but just in case
                leftDomain = true;
            }
        }
        catch(e) {
            // we're here when the child window has been navigated away or closed
            if (child.closed) {
                clearInterval(interval);
                alert("closed");
                return; 
            }
            // navigated to another domain  
            leftDomain = true;
        }
    }, 500);
}
</script>
</head>
<body>
<button onclick="Go()">Go</button>
</body>
Community
  • 1
  • 1
dark_shadow
  • 3,503
  • 11
  • 56
  • 81
  • If I understood your question correctly... in case the child windows doesn't navigate back to the *same original domain as of its parent window*, I don't think you can close it or communicate with it somehow else. That would be a security hole. – noseratio Oct 09 '15 at 22:09
  • @Noseratio: No, I think I'm not able to explain the question properly. The case is when there is no actual change from one domain to another and then back to same domain. somehow, there is some redirection taking place. If you use facebook like social network login, then at first pop up window works exactly as expected in the code. But second time, there is no actual redirection to facebook. It's just that some internal redirection may be based on cookies happens which ultimately redirects to the final redirect url configured in the app. Now, as such code doesn't work as there is no actual – dark_shadow Oct 11 '15 at 13:17
  • change in the domain which is happening. How do I fix this case. In this case, window remains open. – dark_shadow Oct 11 '15 at 13:18

1 Answers1

1

Taking your comments into account, I don't think there's an nice and universal solution to this, unlike with the answer you linked.

A dumb attempt at solving this might be to use a timer and poll the value document.documentElement.innerHTML, for the child window and its all sub-frames.

If the whole structure has been steady for a reasonably long time-lapse (i.e., no changes in HTML and no exceptions thrown), it might be an indication that all internal navigation or XHR calls have been completed, and it's OK to close the window.

noseratio
  • 59,932
  • 34
  • 208
  • 486
  • Any idea how will I accomodate this change in existing function ? Also, will this result in increase in overhead ? – dark_shadow Oct 12 '15 at 06:11
  • @dark_shadow, this is as much as I can help here. Coding this logic should be quite trivial - but as I said - it might not work at all for your particular case. Feel free to experiment and post your version. The overhead shouldn't matter, if you poll with a sensible interval, e.g. 250ms. – noseratio Oct 12 '15 at 10:33