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 <j...@6bit.com> 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 <scarter28m-goo...@yahoo.com> 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. Sent from: Madison Wisconsin United States.
