While Rails has one auth system currently, there are others for Rails and there will be other still to come. Which is at is should be I think, not that Rails HAS such and such a system.

For my own framework (PHP) that I have used for several clients, I have all the auth and user access functions defined in one file, and I have been able to insert my app into drupal, twiki, xoops quite easily.

_Reading the last post would help greatly for this one, and I should note that this post does end up comparing aspects of Django with Rails _ As I mentioned in my last post, Rails has been greatly helped by…

It’s the main reason I’m sticking with Plone.

But yeah, I agree with Ian Bicking. A while back, why didn’t anyone develop something in Apache to handle universal authentication.

I mean, try explaining to people in a company intranet that, yes, they need to log into Bugzilla, and yes, they need to log into the CRM…

Ultimately, though, I don’t think applications are the right place to handle authentication (authorization definitely, but not authentication). It works fine when you have one app. It works fine when you are a 100% Rails, or 100% Django, or 100%-whatever shop. But really, how realistic is that? If there’s anyplace that is ripe for inter-framework and inter-language cooperation, authentication is it.

Pretty much always comes down to numerous people saying “it’s dependent on your specific situation”. Seems to me most of the time it isn’t though, and what makes Rails (and others) so handy for rapid dev is they acknowledge most apps are similar in more ways than not. But still most leave out this component. I don’t understand why really…

Here’s a a summary of what I consider “authorization” security:
I want joe-user to be able to edit only his data, and I want joe-user to be able grant read/edit access to other friends of his choosing, and I want some folks in Finance to edit anyone’s content, including joe-user’s.

The common pattern for this is with roles and permission lists. Joe has a “user” role and has the “create timesheet” permission. Suzy in Finance has the “finance” role, and thus inherits the “create timesheets for anyone” permission. And sharing is taken care of with “grant” options.

This authorization setup is “been there, done that” kind of stuff in Windows, Linux, ERP apps like PeopleSoft, and relational databases like Oracle, and in Zope/Plone. I’ve had a tough time trying to find how to do this kind of thing in Rails and CherryPy. (I don’t want to pick on Django too much on this point since it is so new, and I’m still kicking its tires.)

The Rails wiki chapter on security covers plugging security holes— not authentication, nor authorization. The Salted Hash Login Generator wiki page has a big warning at the top saying “This appears to be broken in rails 0.13″. And many blog posts I read about “my first rails app” seem to mention the work they did on rolling their own user permissions models and code.
A famous post comparing Rails to Java briefly mentions rolling his own security authorization. (http://www.relevancellc.com/blogs/?p=31) When the post was slashdotted, no one seemed to comment to the fact he had to write his own authorization code. (This is odd to me, but maybe no one else thinks so?) I see that the table of contents in “Agile Web Development in Rails” includes a sub-section called “Limiting Access”, perhaps that is what I’m looking for… But do I really have to spend $22.50 to get this kind of information?

Maybe this kind of stuff is just so much easier to write in Rails, but I doubt it. Plus, I feel authorization is something that should be in the framework, with lots of eyeballs looking at it to plug holes in the common parts. Imagine if you had to roll your own user, roles and permissions machinery on every OS install you did!

I’d be very, very happy if I was proven wrong about this, and someone could point out Rails’ philosophy on roles, permissions, and user access. (Perhaps I should ask this question on the Rails mailing list or IRC before I make any more sweeping generalizations. :-)

The Ajax accesibility issue – well, there is nothing inherent in the Rails approach that stops people using it in an accessible way – I think you’ll find that many people using Ajax outside of Rails aren’t considering the accessibility issues either. And don’t get caught up with blind people – if you want to support them you have a whole lot more work to do than not using Ajax – accessibility is about making websites accessibile to as many people as possible, and that includes people with older browsers (note I said accessible, not looking and behaving the same – the two are very different).