I really like that, Brooks. I was worried that this type of page might be stopped by popup blockers, but I suppose it works because you're using a button and not a link (please confirm).
On Mar 21, 1:17 pm, Brooks Bennett <bsbenn...@gmail.com> wrote: > 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 <ivan.kiri...@gmail.com> 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 <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.- Hide quoted text - > > - Show quoted text -
