[jira] Updated: (SHINDIG-480) better handling for the OAuth popup window

["Brian Eaton (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SHINDIG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Eaton updated SHINDIG-480:
--------------------------------


Smart OAuth service providers will put frame busting code in their approval pages, to avoid UI overlays.  For example:

- attacker creates an iframe to the approval page
- attacker overlays the iframe with a frogger game
- as user is playing frogger they click the "OK" button on the approval page.

> better handling for the OAuth popup window
> ------------------------------------------
>
>                 Key: SHINDIG-480
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-480
>             Project: Shindig
>          Issue Type: New Feature
>          Components: Gadget Rendering Server (Java)
>            Reporter: Brian Eaton
>         Attachments: index.html, popup.html
>
>
> Background: OAuth works as follows:
> 1) Gadget developer registers with an OAuth service provider and provides their OAuth callback URL.  The service provider will redirect the user to the callback URL once authorization is complete.  the gadget developer receives a consumer key and secret that is used to identify their OAuth consumer (in this case, their gadget.)
> 2) Gadget developer provides gadget URL, consumer key, and consumer secret to the gadget container.  The container stores the key and secret somewhere the OAuth proxy can use it.
> 3) When the gadget is first rendered by a user, the user needs to visit the OAuth approval URL to approve access.  The gadget creates a link or button that opens a pop-up for this purpose.
> 4) The popup takes the user to the OAuth service provider, where they approve access to their data.
> At this point, the user experience starts to suck.  The user has to close the pop-up window manually, and then they click a link in the gadget saying "I've approved access".  We need to provide some tools to make this a little better.
> Work item #1: 
> The first piece we need to provide are some guidelines about how to open the pop up window.  Popup blockers are an issue, and closing the window is an issue.  There are guidelines from both Microsoft and Mozilla about how to open and close popups:
> Mozilla guidelines: http://developer.mozilla.org/en/docs/DOM:window.open
> Microsoft guidelines: http://msdn.microsoft.com/en-us/library/ms537632(VS.85).aspx
> We could either provide a standard function to open a pop up window, or we could give developers sample code.  I lean towards providing sample code, though I could be persuaded either way.  I don't want to get involved in creating DOM elements for developers, because developers themselves are in the best position to figure out the UI for their gadgets.
> Work item #2: 
> The second piece we need to provide is a way for gadget authors to detect when the pop up window is closed.  There are a few mechanisms to do this.
> The simplest way I can think of is to poll for the win.closed property with window.setInterval.
> One gadget developer did something more complicated:
>   - added the gadget URL as an extra parameter on their callback URL.
>   - wrote a web application themselves to handle the callback
>   - when their web application ran, it rendered the gadget on gmodules.com using an extra parameter on the URL
>   - when the gadget initialized, it checked for the extra parameter
>   - the second instance of the gadget then called back into the first instance via window.parent.opener.document to trigger the request to get the data.
> I'm leaning strongly towards polling with window.setInterval.
> Work item #3: provide a standard callback URL for gadget developers.
> Each container should provide a standard callback that developers can use when they register their gadget.  The callback URL can point to some javascript provided by shindig that just does a window.close(), and possibly includes some text that says "Please close this window" just in case the window.close() doesn't fire (e.g. javascript is disabled, or the browser refuses to close the window because it wasn't opened by javascript.)
> To summarize, I want to
> a) modify shindig to provide a trivial OAuthCallbackServlet that just calls window.close().
> b) modify the oauth.xml sample gadget to use javascript to detect when the window has been closed and automatically re-request the user's data.
> Comments, questions, objections?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.