Scott is correct here. As a policy, web sites should never allow sign in through an iframe, as even the minority of users smart enough to verify the source URL is twitter.com can't verify it.
Ivan http://tipjoy.com On Mar 20, 11:24 pm, Scott Carter <scarter28m-goo...@yahoo.com> wrote: > 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 <4bra...@gmail.com> 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 <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. > > Se"nt from: Madison Wisconsin United States.
