I whipped up a quick and dirty fix. Need to clean it up more, but it works (this demo is subject to come down in the very near future)...
The page is: http://tweetchat.com/iframe Load it into an iFrame with the following tacky script: <iframe src="http://tweetchat.com/iframe/"; style="height:400px; width: 800px; border: 10px dotted pink;"></iframe> All I did was build the authorization link, but have it open in a new child window via javascript. Set your application to have a callback URL of a child page that handles the returned information, refreshes the parent window and then closes itself. It is the best thing I could come up with on the quick, but at least there will be an easy way (hey even I could dream it up) to balance security with functionality... Brooks On Mar 21, 12:33 pm, Ivan Kirigin <[email protected]> wrote: > 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. > > Ivanhttp://tipjoy.com > > On Mar 20, 11:24 pm, Scott Carter <[email protected]> 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 <[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.
