Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

oAuth WIndow callback in Internet Explorer #7

Open
smokeyjohnson opened this issue Oct 2, 2015 · 1 comment
Open

oAuth WIndow callback in Internet Explorer #7

smokeyjohnson opened this issue Oct 2, 2015 · 1 comment
Assignees
Labels

Comments

@smokeyjohnson
Copy link

It appears that by default security settings (protected mode) in Internet Explorer stop the callback from happening from the child window to the parent. The Umbraco property editor is never updated. This appears to be a widespread issue with Window communication in protected mode. Is there a more reliable way of doing this rather than using a callback from the child window?

A number of options seem to be around but all none of them seem to get around this issue; Like using a timer in the parent window and checking the window.location of the child window to see when it has returned from the external Twitter url... and then grabbing the result... but again when the window redirects to an external (https?) url, the handle on the window seems to change and a permission denied error results (which can be caught). However even when the window returns to the same domain as the parent, Internet Explorer still doesn't seem to make the window handle object fully available again.

Apart from redirecting the entire page to the Twitter authorisation page and then back I can't seem to find a fully cross browser reliable way of doing this in-line (and a full page redirect wouldn't really be acceptable in the Umbraco backend).

@abjerner
Copy link
Owner

abjerner commented Oct 3, 2015

Hi and thanks for reporting,

I can confirm the issue, but the window callback seems to be working fine (default settings in IE11).

What seems to be the problem is instead that AngularJS doesn't trust the data from the postback, and therefore triggers an error. I don't have a solution at the moment, but will look further into it ;)

@abjerner abjerner self-assigned this Oct 3, 2015
@abjerner abjerner added the bug label Oct 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants