Skip to main content

Using Twitter @Anywhere Bridge Codes

Update: Twitter has removed oauth_bridge_code support from the API

At @appworkshop in July @themattharris pre announced @Anywhere oauth_bridge_code support. The official announcement has yet to appear but this blog post provides everything you need to get started.

An @Anywhere oauth_bridge_code can be used to get a long lived OAuth 1.0a access_token for the REST API. This allows sites to use @Anywhere and the REST API while only requiring users to only use one authentication method.

The basics are that after a users completes the sign in process for @Anywhere the browser gets an oauth_bridge_code. This oauth_bridge_code can be passed to the /oauth/access_token API endpoint signed with your applications consumer key and secret. If everything checks out Twitter will return a standard access_token for the REST API.

Now lets see some code!

Lets start with authenticating the user using the direct link method described in Hacking Twitter OAuth. You will need to change the oauth_client_identifier to you applications OAuth 1.0a consumer key (AKA your @Anywhere API key) and oauth_callback_url to a URL authorized for the application.


Redirect the user to that URL will be prompt them to connect with your application before being redirected to the oauth_callback_url. Attached in the oauth_callback_url fragment will be an oauth_access_token and am oauth_bridge_code.


Now make a signed POST request to https://api.twitter.com/oauth/access_token using your applications consumer key and secret.


Awesome! You now have a OAuth 1.0a access_token as if you had used the standard OAuth flow with the @twitterapi.

Lets look at getting the oauth_bridge_code using @Anywhere's connect button. This code is a simple HTML document that displays an @Anywhere connect button and handles authComplete on the users return. The oauthComplete uses @jQuery to post the oauth_bridge_code to convert.php which does the same conversion we already saw.


Catch the POST and convert the oauth_bridge_token to an access_token as described above.


An alternative method to verify @Anywhere users, instead of calling verify_credentials with their access_token, is to compare the sha1 hash of their user_id concatenated with the consumer_secret with the value of the twitter_anywhere_identity cookie.


You can read the source information on the slides @themattharris put together for @appworkshop. Skip to page 51.

Comments

  1. Is it possible to go the other way?
    e.g. Use the standard OAuth flow to generate a 1.0a access token, and then somehow obtain a @Anywhere token also.

    ReplyDelete
  2. Anonymous: If you can go one way there really isn't any need to go the other way.

    ReplyDelete
  3. Thank you SO much for this, but question: I can't seem to capture the oauth_bridge_token when using the authComplete listener (for a .signIn() method used on a generic login button.)

    Does this not work unless you use Twitter's .connectButton?

    ReplyDelete
  4. Not needed, but in my case it would be quite helpful: I do not intend to use the @anywhere connect button, and I already have OAuth 1.0a working. Now I want to use T.isConnected() feature from @anywhere, but I have to completely change the verification process in order to do so.

    I am to the point where I retrieve the access token using the oauth_bridge_token, but I keep getting 401s.. I will get eventually, but it would be easier if it I could go the other way.

    ReplyDelete
  5. Correct me if I am wrong but - Even after converting the bridge token into a long-term oauth 1.0a token, then verifying and storing the auth token and secret - there are still only a few hours where the @anywhere script recognizes the logged in user. if the user comes back the next day, you have to go through the motions all over..
    much different and less useful than facebook connect - where the logged in user is connected to an app automatically after the first time they authorize it.. that is what makes it suitable for use as authentication. essentially T.isConnected() should return true if the user is logged in to twitter, and has previously authorized the app.
    I noticed - there does not seem to be an "authenticate" endpoint for the oauth 2, only "authorize".. the 1.0a implementation has both endpoints, and I always used authenticate, not sure if that is my issue.

    ReplyDelete
  6. not to mention my custom authComplete callback function is getting called multiple times (between 1-3) and obviously it fails after the first attempt, since it has already exchanged the token.

    ReplyDelete
  7. Anonymous: If you already have the standard Sign in with Twitter flow implemented that switching would be more work. You don't have to use the @anywhere connect button. You could just use a link or even the existing Sign in with Twitter button.

    Yes @anywhere tokens are short lived. About 3 hours.

    ReplyDelete
  8. EvilJordan: Not sure. I've never tried it with the signIn() method. I would think that it should work though.

    ReplyDelete
  9. @abraham Yes, I formulate my own auth link, I am not using the connect button.

    The problem comes when I use an ouath 1.0a link. there is no way to make @anywhere honor the returned token.

    however, even when getting the @anywhere token / bridge, the @anywhere portion is only good for a few hours, so its not worth the bother.

    is there anything closer to facebook connect in the twiiter api?

    ReplyDelete
  10. Anonymous: @anywhere is as close to Facebook Connect as you will get from Twitter.

    @anywhere tokens only last a short period because if someone gains access to them they allow access to all of the users data. There is no secret hidden in a server somewhere to help protect the user longterm.

    ReplyDelete
  11. when a user who is logged into twitter and has authorized my app returns to my @anywhere page -
    twitter should be checking twitter.com cookies on the back-end (iframe etc.), and executing a callback on my page to let me know the current user is logged in and auth-ed. there should be no interaction needed with any ui, it should be part of loading the anywhere script.

    that flow is unrelated to an anywhere token. it only requires the bridge - or better just a regular oauth token / verifier..

    with no secret and expiring the token so quickly, it just doesn't seem like real security. fine by me, i prefer rest apis over client apis anyway.

    i would hope that the anywhere token is only good for requests made with a particular request signature - 1. domain, 2. public key, 3. token, etc.

    but even then, twitter would need to take care when passing data (particularly domain name) between the anywhere js functions on the page and the iframes that do the actual back-end work. there are straightforward ways to trick this process without proper precautions.

    ReplyDelete
  12. Thank you SO much for this, but question: I can't seem to capture the oauth_bridge_token when using the authComplete listener (for a .signIn() method used on a generic login button.)

    Does this not work unless you use Twitter's .connectButton?

    ReplyDelete
  13. Anonymous: If you can go one way there really isn't any need to go the other way.

    ReplyDelete
  14. It looks like Twitter stopped accepting bridge codes:
    http://groups.google.com/group/twitter-development-talk/browse_thread/thread/50fcc4f28cd6b659/

    ReplyDelete
  15. I think they should rename @Anywhere to @Nowhere, how difficult could it be to work the same way FB.api does?

    Twitter Documentation :Poor
    Twitter ObjectModel :Poor
    Twitter OAuth Implementation:Poorest

    The only thing I'd hope from Twitter is an 'override', extra param or whatever to which I can pass an OAuthToken so I can sign in with a know token, without having to make my user travel around the web with his credentials, from IFrame to IFrame.

    ReplyDelete

Post a Comment

Popular posts from this blog

Little known @Twitter and @TwitterAPI tips and tricks

Be sure to comeback as new tips and tricks get added. If you know of anything I missed be sure to let me know.

Static URL for profile images based on screen_name:

https://api.twitter.com/1/users/profile_image/abraham

* This performs a http redirect to the actual profile image URL. Currently https redirects to http. You can also add "?size={mini | bigger | normal}" to get specific sizes.

Redirect to profile based on user_id:

https://twitter.com/account/redirect_by_id?id=9436992

In_reply_to_status_id mentions:

https://api.twitter.com/1/statuses/update.json?status=reply+to+@abraham&in_reply_to_status_id=12410413197

* In the web interface new mentions are only replies if they start with @screen_name. By pushing @screen_name further along in the string your followers who do not follow @screen_name will still see the status.

Profile image sizes:

http://a3.twimg.com/profile_images/54160223/chart-black-small.png

* By default you get the original image size you can add _mini, _normal, and …

Installing Storytlr the lifestreaming platform

"Storytlr is an open source lifestreaming and micro blogging platform. You can use it for a single user or it can act as a host for many people all from the same installation."

I've been looking for something like Storytlr for a few months now or at least trying to do it with Drupal. While I love Drupal and FeedAPI I did not want to spend all that time building a lifestream website. So I've been playing around with Storytlr instead and found it very easy. Here is how I got it up and running on a Ubuntu EC2 server. You can also check out the official Storytlr install instructions.

Assumptions:
LAMP stack installed and running.Domain setup for a directory.MySQL database and user ready to go.Lets get started!
Get the code: wget http://storytlr.googlecode.com/files/storytlr-0.9.2.tgz tar -xvzf storytlr-0.9.2.tgzYou can find out the latest stable release on Storytlr's downloads page.

Import the database:
Within protected/install is database.sql. Import this into your empt…

Sync is currently experiencing problems

Update: I now recommend you install Google Chrome and disable the built in Browser as it supports encrypting all synced data.

After picking up a gorgeous Galaxy Nexus yesterday I was running into an issue where my browser data wasn't syncing to the phone. After a little Googling I found this is commonly caused by having all of my synced Chrome data encrypted instead of the default of only encrypting the passwords. These are the steps I went through to get my dat syncing again without losing any of it. The exact error I was getting was "Sync is currently experiencing problems. It will be back shortly."




In Google Chrome open the personal stuff settings page by clicking this link or by opening the wrench menu, and click on "signed in with example@gmail.com".  Hit "disconnect your Google Account" to temporarily disable syncing from your browser.



Visit the Google Dashboard and "Stop sync and delete data from Google". I waited until the stored dat…