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
