Rails authentication with Authlogic and RPX
The Singapore Ruby Brigade had it's monthly meetup last night. Great discussions as always, and how can you complain when you get to carry on over maggi mee goreng supper until the wee hours;-)
Here are the slides from my talk about Rails authentication options in general, and specifically why and how to use RPX with Authlogic (using the Authlogic_RPX gem I released last week).
read more and comment..
Released: Authlogic_RPX gem, the easiest way to support multiple authentication schemes in Rails
I've just made Authlogic_RPX public for the first time and invite any rails developers to take a look. It's a ruby gem that adds suppport for RPX authentication in the Authlogic framework for Ruby on Rails. With RPX, you get to support all the common authentication schemes in one shot (Facebook, twitter, OpenID etc).
Authlogic_RPX is available under the MIT license, and a number of resources are available:
- Authlogic_RPX source repository: github.com/tardate/authlogic_rpx
- Live Demonstration Site: rails-authlogic-rpx-sample.heroku.com
- Demonstration site source repository: github.com/tardate/rails-authlogic-rpx-sample
The best place to find out more is the README, it contains the full background and details on how to start using it. Feedback and comments are welcome and invited (either directly to me, or you can enter them in the github issues list for the project).
Authlogic_RPX plugs into the fantastic Authlogic framework by Ben Johnson/binarylogic. Authlogic is elegant and unobtrusive, making it currently one of the more popular approaches to authentication in Rails.
RPX is the website single-sign-on service provided by JanRain (the OpenID folks). It complements their OPX offerings I wrote about recently. RPX abstracts the authentication process for developers and provides a single, simple API to deal with. This approach is great for developers because you only need to build a single authentication integration, and leave to JanRain the messy details of implementing and maintaining support for the range of authentication providers: OpenID, OAuth, Facebook Connect, AOL, Yahoo, Google, and so on..
If you want to learn more, there was recently a great podcast interview with Brian Ellin from JanRain on the IT Conversations Network: RPX and Identity Systems
read more and comment..
Twitpocalypse II: Developers beware of DB variances
Alert: "Twitpocalypse II" coming Friday, September 11th - make sure you can handle large status IDs!
Twitter operations team will artificially increase the maximum status ID to 4294967296 this coming Friday, September 11th.
"Twitpocalypse (I)" occured back in June, when twitter and application developers had to deal with the fact that message status IDs broke the signed 32-bit integer limit (2,147,483,647).
At that point, the limit was raised to the unsigned 32-bit limit of 4,294,967,296. Now we're heading to crack that this week. You can track our collective rush to the brink social celebrity meltdown at www.twitpocalypse.com;-)
First reaction: OMG, it's taken only 3 months to double the volume of tweets sent over all time? That's a serious adoption curve.
Next reaction: once again, application developers are reminded that we unfortunately can't ignore the specifics of the database platform they are running on and just take it for granted.
It's actually quite common for development and production infrastructure to be subtly different. This is especially true in the Rails world where SQLite is the default development database, but production systems will often be using MySQL or PostgreSQL.
If you are using a hosted ("cloud") service it may even take some digging to actually find out what kind of database you are running on. For example, if you use Heroku to host Rails applications, most of the time you don't care that they run PostgreSQL (originally I think they were using MySQL but migrated a while back).
It's in situations like Twitpocalypse that you care. With a Rails-based twitter application, use an "integer" in your database migrations and you will have no problem running locally on SQLite, but you're app will blow up on a production PostgreSQL database when you encounter a message with status_id above 2,147,483,647.
Fortunately, the solution is simple: migrate to bigint data types.
And the even better news is that ActiveRecord database migrations make this a cinch if you have been using integer types in the past. For example, if you've been using an integer type to store "in_reply_to_status_id" references in twitter mentions table, the change_column method will happily manage the messy details for you:
class ForcebigintMentions < ActiveRecord::Migration
change_column :mentions, :in_reply_to_status_id, :bigint
change_column :mentions, :in_reply_to_status_id, :integer
It's always a good idea to check fundamental limits for the database platforms you are using. They are not always what you expect, and you can't safely apply lessons from one product to another without doing your homework.
Here's a quick comparison of integer on some of the common platforms:
- SQLite: INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value. i.e. will automatically scale to an 8 byte signed BIGINT (-9223372036854775808 to 9223372036854775807)
- PostgreSQL: INTEGER 4 bytes (-2147483648 to +2147483647). Use BIGINT for 8 byte signed integer.
- MySQL: INT (alias INTEGER) has a signed range of -2147483648 to 2147483647, or an unsigned range of 0 to 4294967295. Use BIGINT is the 8 byte integers.
- Oracle : NUMBER type ranges from 1.0 x 10^-130 to but not including 1.0 x 10^126. The activerecord-oracle-enhanced-adapter provides facilities for intepreting NUMBER as FixNum or BigDecimal in ActiveRecord as appropriate.
PS: there's been some discussion of why twitter would schedule this update on Sep 11th and publicise it as the Twitpocalypse II. I hope it was just an EQ+IQ deficiency, not someone's twisted idea of a funny or attention-grabbing stunt.
read more and comment..
OPX: Almost, but not quite, what we need to get the Enterprise on the cloud?
A post today by Dana Gardner - Cloud adoption needs a support spectrum of technology, services, best practices - got me thinking again about the importance of a universal "business" identity to make cloud computing a reality for the enterprise sector.
I wrote some time ago about OpenID - the missing spice in Enterprise 2.0? The basic premise being that for Enterprises to truely exploit the exploding cloud offerings, they first need a way of exporting business identities to the web.
While most businesses at the moment have not officially adopted cloud services, the reality is that cloud services are already penetrating all organisations - whether it is sales people keeping touch with contacts on twitter, pre-sales engineers collaborating via google docs, or consultants using drop.io to get around email size restrictions when sending documents to partners and customers.
The issue I wrote about in my previous post is that we need to wake up and recognise that the flood gates are already open: we are mixing personal and business identities in a tangled mess that is becoming harder to unravel each day.
The risk for business? While free cloud services are giving a tactical boost, when employees move on, they will take all of their cloud-attached contributions with them. At best, a relationship management issue to recover, at worst you find all kinds of SOX and compliance issues lurking to bite back.
Now pretty much all IT-enabled organisations have a form of internal directory and authentication service (be it AD or an LDAP variant). My premise is that organisation do want to be able to exploit google apps, Zoho or Salesforce, but when doing so, we should care deeply that employees apply their business (not personal) identity to any transaction.
From a technologist's point of view, this essentially means that we want to take our internal authentication processes and expose them in a very controlled way on the web. SAML was the deathstar standards approach, but I think in reality OpenID has won the hearts and minds at this point.
One of my projects-on-the-drawingboard is an OpenID provider designed for the Enterprise - a drop in module that allows you to export internal identities from AD or LDAP in a very controlled and auditable way. It is still on the drawing board and has been for ages - if others are interested in making it reality, drop me a line.
However, I think the options may already be available. I am talking about janrain's OPX, although I'm not sure that any of their offerings are really designed for this specific scenario. Even the OPX:Groups offering, which seems to be the closest seems to require establishing a new directory of identities rather than leverging your existing assets. I may be wrong... still investigating and certainly appreciate a steer in the right direction.
read more and comment..