I think Ivan's suggestion could answer the concern about the case where a user needs to enter a username/password: "If not signed in, a new window could load with the regular OAuth process. "
For the case where the user is already logged in, there doesn't appear to be any risk here. Consider the scenario where the IFRAME is populating a page from a site pretending to be Twitter with an Allow/ Deny button. By clicking "Allow", nothing bad can happen. Twitter isn't Allowing anything in this case since it wasn't their page to begin with. FYI - I think my case is different than Ivan's since he is discussing a widget whereas my app lives entirely in the IFRAME. The callback from Twitter after authorization would simply cause the IFRAME to redirect back to a page on bigtweet.com where I could then present a different (logged in) view for the user. Joshua's suggestion would work, but providing IFRAME support with a callback URL would save the user two steps - needing to close the Authorization window, and clicking the Complete Connection button. Scott On Mar 20, 5:50 pm, Abraham Williams <[email protected]> wrote: > If you have the approval process take place in the iframe there is no way to > for the user to actually verify they are interacting with twitter. if they > are not logged into twitter already you are then asking users to enter > username/password on a potentially unsafe site and opening up to fishing. > > > > On Fri, Mar 20, 2009 at 16:29, Joshua Perry <[email protected]> wrote: > > > The interesting thing is, that you could omit the callback URL in your > > application registration with Twitter. On your site when the user clicks > > the "connect twitter" button you would go and grab a request token and pop a > > new window with that request token in the URI like usual. The user would > > click accept and since there is not a callback URL Twitter will say "You can > > close this window and complete the Connect process". Waiting on your > > webpage would be the "complete connection" button which, when clicked, would > > request Twitter to convert the request token into an access token. > > > Instead of popping a window I don't know why you couldn't load the Twitter > > authorization page into an IFrame, but the message to "close this window" > > may be a bit confusing to the user. > > > This flow is the same as a desktop application has to use to accomplish an > > OAuth connection and should work the similarly well with a web application. > > > Josh > > > Ivan Kirigin wrote: > > >> I'd love to be able to do this also, and have mentioned it off the > >> list. > > >> Imagine a "Twitter Connect" button, which would be a tiny iframe > >> loaded from twitter.com. If signed in, the token exchange could take > >> place right there. If not signed in, a new window could load with the > >> regular OAuth process. The callback in the button would be to a tiny > >> iframe acting as a confirmation of the success, loaded by the > >> consumer. > > >> There is a diminished phishing risk, because the widget isn't asking > >> for your password. Only the new window would. > > >> The only question is how the rest of the widget gets the notification > >> that the OAuth access grant has taken place. My thought is that the > >> widget could just ping the web service to see if things are integrated > >> properly. Cross domain iframe communication is a HUGE pain in the ass. > >> You can get around it if the twitter iframe loaded a designated hidden > >> iframe from the 3rd party. > > >> Alternatively, you could ask the user to refresh the widget / > >> bookmarklet. > > >> Generally, I'd like to see some standard buttons from twitter, so > >> normalize the OAuth experience. You can see on the top of > >>http://tipjoy.com > >> a banner we made that uses twitter fonts and colors. > > >> Best, > >> Ivan > >>http://tipjoy.com > > >> ps check out our twitter payments api:http://tipjoy.com/api > >> feedback welcome! > > >> On Mar 20, 3:00 pm, Scott Carter <[email protected]> wrote: > > >>> I'm starting to look at the OAuth process and had a question for the > >>> OAuth folks at Twitter. > > >>> My application BigTweet is invoked via a bookmarklet and displays as > >>> an IFRAME on any web page that a Twitter user happens to be > >>> browsing. Ideally I would like to be able to complete the entire > >>> OAuth process within the IFRAME (for initial login). > > >>> I believe that Twitter recently added measures to prevent framing of > >>> their site to stop phishing attacks. Does this extend to the OAuth > >>> approval page? Could an exception be made for the OAuth page when > >>> invoked from a registered application presenting a valid Request > >>> Token? If so, could this be documented (perhaps in the OAuth Twitter > >>> FAQ)? > > >>> The authorization page at Twitter appears to have a fairly small > >>> content section (with Deny/Allow buttons, etc), which could fit into a > >>> reasonably sized IFRAME. If you are agreeable to allow IFRAME > >>> support, would it be possible to standardize on content dimensions > >>> (for IFRAME sizing) and document this as well? > > >>> Thanks for considering my request. > > >>> Scotthttp://twitter.com/scott_carter > > -- > Abraham Williams |http://the.hackerconundrum.com > Web608 | Community Evangelist |http://web608.org > This email is: [ ] blogable [x] ask first [ ] private. > Se"nt from: Madison Wisconsin United States.
