[
https://issues.apache.org/jira/browse/SHINDIG-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620000#action_12620000
]
Bob Evans commented on SHINDIG-480:
-----------------------------------
Given that the authorization popup should be just a bit of explanatory text,
maybe a logo, and a username/password combo, what about just rewriting the
content of the gadget so that it renders the popup inline. That way you could
get around popup blockers, and write a callback that determines when the user
finished the transaction, or that has a button back to the gadget's regular
contents.
> 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.