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

Make adal.js working within an iFrame sandboxed environment #129

Closed
bpatra opened this Issue May 22, 2015 · 8 comments

Comments

Projects
None yet
4 participants
@bpatra
Copy link
Contributor

bpatra commented May 22, 2015

This is more a feature request, an enhancement, than an issue. Actually, I think adal.js should be working when embedded within an html5 sandboxed iframe.

Wait! this is not as stupid as it looks because sandboxed iframe is the runtime environment of the new app for office model. It would be really nice to have access to the azure ad (and therefore office 365 REST API) from an office 365 app. See documentation here

Currently adal.js is not working, because of the use of window.location.replace(urlNavigate); line 361 7a5480e of adal.js
Actually, it behaves differently in a sandboxed environment and creates a popup or displays an error message depending on the browser's implementation.

Fortunately, we do not require the enhancement to work in the most restrictive sandboxed environment where javascript is disabled. I remarked that the sandbox parameters in the app for office are the following ones * sandbox="allow-scripts allow-forms allow-same-origin ms-allow-popups allow-popups"*

I started a sample here where I created a replication environment (that does not require office) with just a sandboxed iframe. You can view it on this remote branch on my fork.I will try to provide a fix because I need it to release my app.

Any help or thought is welcome.

Thank you very much.

bpatra added a commit to bpatra/azure-activedirectory-library-for-js that referenced this issue May 24, 2015

First 'hacky' implementation to address issue AzureAD#129
We check if the 'current' window is iframed. If not we keep the usual logic.
Otherwise, we pop a new window with the right url to https://login.microsoftonline.com/etc..., when the url is changed (after clicking SignUp)
we close the popup and use this new url for the parent iframe.
@bpatra

This comment has been minimized.

Copy link
Contributor

bpatra commented May 28, 2015

Create a blog post about the 'only' solution I found to overcome this problem.
Asked also the social msdn about the security restrictions and the implementation of the OAUTH in sandboxed environment

@Hihaj

This comment has been minimized.

Copy link

Hihaj commented Aug 18, 2015

@bpatra I've been experimenting with something very similar to the workaround you describe in your blog post, but for use within Dynamics CRM Online (and without knowing about your efforts). My solution is a bit different though; I use a custom displayCall function to open a popup window with the Azure AD login page (which is supported by adal.js) and let the parent window periodically check the popup window's hash to see if the login flow has completed. Then I needed to tweak the handleWindowCallback function of the AuthenticationContext somewhat to allow for the hash to be passed as an argument (instead of it always using window.location.hash) + prevent it from always overwriting window.location.

Moreover I add an event handler in the main window (which would be loaded by Dynamics CRM in this specific use case) that listens for "get user" messages using the window.postMessage API, uses adal.js to get user tokens/user info and returns them to the message sender. This way, any iframed pages (or even scripts on the same page) can request tokens consistently and all the popup and hash checking is handled by a central component.

I'm considering sending a pull request for this pretty minor change to adal.js - I see no reason why it should assume that the login callback always happens in the same window.

@Hihaj Hihaj referenced this issue Aug 18, 2015

Closed

Added hash parameter to handleWindowCallback #160

0 of 1 task complete
@bpatra

This comment has been minimized.

Copy link
Contributor

bpatra commented Aug 18, 2015

@Hihaj this is really interesting. Your PR #160 introduced few changes in adal.js code and looks very neat. I would be interested to see how you use it in your Dynamics app.

@Hihaj

This comment has been minimized.

Copy link

Hihaj commented Aug 18, 2015

@bpatra Have a look at the gist I linked to in the PR comments - it's not a complete solution, but it shows how a central script can request user tokens using popup windows instead of the main window. Expanding on this, one could pretty easily add an event listener in the main window that embedded (iframed) apps can send user token requests to.

@Hihaj

This comment has been minimized.

Copy link

Hihaj commented Aug 18, 2015

@bpatra In Dynamics CRM specifically, window.open is not the best choice though - it opens a window in a separate process unavailable to the script when run in the Outlook client. Instead, I would use Xrm.Utility.openWebResource with a custom "redirect page" (HTML web resource that redirects to a url passed in as the data query parameter) - this ensures that the popup is accessible to the script, which is needed in order for it to extract the hash after a successful login.

@hitendramalviya

This comment has been minimized.

Copy link

hitendramalviya commented Sep 5, 2015

Even I am also running into same issue. @Hihaj how can we use Xrm.Utility.openWebResource instead of window.open.

@Hihaj

This comment has been minimized.

Copy link

Hihaj commented Sep 6, 2015

@hitendramalviya Create a HTML web resource containing a script that reads a url from the data querystring parameter, then redirects (using the window.location API) to that url. So instead of window.open('https://example.com') you would use Xrm.Utility.openWebResource('redirect.html?data=https://example.com') (though the data parameter value would have to be url-encoded (use encodeURIComponent)).

@tushargupta51 tushargupta51 added this to the Future milestone May 11, 2016

@tushargupta51 tushargupta51 modified the milestones: Backlog, Future Jul 20, 2016

@tushargupta51

This comment has been minimized.

Copy link
Contributor

tushargupta51 commented Nov 2, 2016

We added support for pop up based authentication in 1.0.12. Users dont need to hookup displayCall method for this to work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment