Why Rails won't become OpenACS, or "Rails is cool, but can we have a login system?"

Other
Nov 16, 2005
by Calvin Correli
2 min read

Ok, I didn’t mean to say so much on this topic, but I really can’t help myself with the response I’m getting :)

So I’m saying these big application components don’t work.

But come on! No login system? I mean, everybody needs a login system. Let’s add a login system to Rails. Just an itty-bitty login system. Please?

No! (Disclaimer: I don’t get to decide that.)

Seriously, though, the number one request I’ve heard from folks familiar with OpenACS is a login system. But friends, you don’t want your web framework to have a login system.

Why? Look around on the web. How many login systems do you see that are exactly alike? I’ve hardly seen any.

Login systems turn out to be a really hard piece to generalize. Trust me, I’ve tried. Do you use username or email? Do you let people register or create accounts for them? Do you store passwords encrypted, in which case you can’t email them a forgotten password. Do you offer login with Passport or Typekey? Do you verify passwords against a local database or an LDAP server or something else? Or both? What do you do when those accounts aren’t in our database already? Do you ask people for their name and other stuff, or do you get that from somewhere else? Do we ask for their real name, prefix, suffix, etc.? Do we lock people out after x number of failed attempts? Do we use their mother’s maiden name to recover passwords? Do we verify your email before letting you in? Does your login expire, and when, and can the user choose that? Do we still show non-sensitive information even though your login is expired, like Yahoo and Google do on their portals? Or maybe we don’t use passwords, but just hard-to-guess URLs?

The bottom line is that there are lots and lots of meaningful differences.

So you can either take the complex and hard path of trying to build the login system to end all login systems—in which case you end up with lots of complex code that only a few people fully understand, and that still doesn’t cut it for everybody.

Or you can do the Judo and solve the easy problem.

It’s your choice, but I know where I put my money.

Like

About Calvin Correli

I've spent the last 17 years learning, growing, healing, and discovering who I truly am, so that I'm now living every day aligned with my life's purpose.

Read more
Read next

Do you know any Jason Frieds?

5 comments

Mark Aufflick
 

For the benefit of readers (Lars, I know you know this), I respect Lars more than any other developer I have known - as a developer and a thinker. This time Lars, I think you are wrong, or perhaps just not hitting what you want to say. You are talking about a login system, but the re-use component IMO is permissions. I admit to being way out of date as to what is in Rails these days, but the seriously full-on permissions system in OpenACS is one of it's major assets. Developing a login system is easy. Developing a fully recursive, massively scaleable, audited (etc.) permissions system is hard. Not np-hard, but very time consuming. And when someone else adds LDAP support to their implementation of Rails permissions/login, do you get to use it for free when you upgrade? On balance, I totally agree that large scale reuse is an unsolved problem. I have a foot in a number of development camps these days , all of which have their own styles of reuse: * Perl -- CPAN -- low (DBI) to high (Catalyst) level reuse -- API style and upgrade path defined by each package owner * OpenACS -- OpenACS repositary -- low (util procs) to ultra high (bug tracker) level reuse -- API style and upgrade path mandated (sort of) by elected group * Apple Mac development -- random projects released under random licenses -- low level reuse -- API style and upgrade paths usually minimal Just because totally optimal reuse is an unsolved problem doesn't mean we should try to stretch higher. Over time I would hope that we learn ways of increasing our reuse and OpenACS is one of the best I have ever come across. The style of reuse there, however, is fairly domain specific - online collaborative apps. Perhaps the problem comes when you try to apply a style of reuse that suits that domain to other domains. Writing the above bullet points makes me realise that upgrades are closely linked with large scale code reuse. You can't just upgrade the re-used code without a way to do things like upgrading your database schema and data or versioning your api calls... Still - I truly hate implementing a new permissions system for every client Perl project just because they want something slightly different. If I had an OpenACS calibre permission/login system to roll out in Perl I would be truly happy! Perhaps I am the one who hasn't hit the mark. I get passionate about code reuse - perhaps we need to work on a manifesto along the lines of XP. Extreme Reuse :) I need to work on these thoughts some more - cross posting to my blog for further contemplation... Hmm - I don't have trackback on my blog, but I will magically get it when I upgrade my web framework. Now that's re-use ;)
Read more
Read less
Reply about 19 years ago
  Cancel
Lars Pind
 

Well, clearly I've missed your mark (no pun intended), but it's still the request I hear most often. I'm pretty happy to not have to deal with the OpenACS permsisions model, though. It never did what I needed it to do for my projects, and it's impossible to make a UI for it that sane people can figure out to use, because, well, the system model isn't sane. And it didn't perform all too well, even if you remembered to only use the magic stored procedure in the SELECT part, not in the WHERE part. If it does the trick for you, by all means use it. But I find it much faster to build and easier to test and maintain when I build in just the permissions that I need. It's a different way to think about the problem, but given that we've tried the other one for 10 years and it isn't quite working, maybe it's time to stop thinking execution is the problem, and try something different.
Read more
Read less
Reply about 19 years ago
  Cancel
Mark Aufflick
 

Ok, so I've done some more reading and some more thinking. I can't help seeing that you are right, but the damn "Analytical" personality in me keeps seeing re-usable concepts everywhere in life - if only we could generalise them enough! And perhaps that's really it. Perhaps life is not general in the way we have thought. Perhaps life isn't best optimised in the same way as a least cost routing algorithm. Most applications are, after all, about augmenting human activites.
Read more
Read less
Reply about 19 years ago
  Cancel
Mark Aufflick
 

Having just read the article by Robert Glass, it reminds me about the reason that I stayed with OpenACS when ArsDigita folded. People are important. TCL is unsexy. In fact it's down right annoying. Possibly even more so than Java. Who hasn't wasted 30 minutes on a missing space or badly quoted list or on trying to understand Lars's upvar genius :) The OpenACS framework is powerful, but the learning curve is steep. So many reasons to leave it alone. But in the ACS/OpenACS community I found people who would (and did) help me grow. I learned more about being a great developer from members of the OpenACS community than from my degree or all the corporate environments I have worked in. Those same people were why I was confident that OpenACS was a good technology platform to base my business on. Unfortunately, as time continues to leave the era of the Internet's birth and Arsdigita behind, the OpenACS community is changing (for possibly unrelated reasons). More than that, the technology community is changing. Some of the wonder and the fun seems to have gone. I even thought about giving technology away all together. If we can't make large scale reuse work, are we doomed to repeat the same work over and over again? What is next? What is going to be great about this decade that we will look back and say "wow, look at how far we have come". I think part of what you are saying Lars, is that sometimes it's time to stop flogging the same dead horse. If it's true that now is that time, then lets not just jump on another horse and do the same thing in a similar direction - what we need is to step back and decide where to go next. Big picture. I sometimes get frustrated that I don't have the institutional luxuries of Xerox Parc and I am just a little too young to have accessed the millions of easy dollars of dotcom VC funding. But if I don't start to dream and then run to achieve those dreams, then I may well wake up in 20 years in a world that is not all I had hoped. This comment feels a little melodramatic! And how is it related to the original topic? I think that sometimes we fall into exactly the trap that Glass talks about. It is nice to believe that a change in the systems and technologies that we use will take us to where we want to go. In reality though, it is people and vision and relationship that is what we need. Anything else will fall short of what we desire. Just to return us to the topic to finish off, let's see what Glass has to say about whether reuse-in-the-large is at all feasable: <blockquote><i>OK, so reuse-in-the-large is a difficult, if not intractable, problem. Is there any way in which we can increase the odds of making it work? The answer is "yes." It may be nearly impossible to find components of consequence that can be reused across application domains, but within a domain, the picture improves dramatically ... Software people speak of "families" of applications and "product lines" and "family-specific architectures." Those are the people who are realistic enough to believe that reuse-in-the-large, if it is ever to succeed, must be done in a collection of programs that attacks the same kinds of problems.</i></blockquote> And with that I bid you good night!
Read more
Read less
Reply about 19 years ago
  Cancel
rolf
 

I agree with your other post where you say a framework should make building a login system easy, rather than providing a login system itself. However, I will add the following data points: I've built six web applications that are still being used, and the login system was nearly identical in each one. If you download any of the half-baked PHP web forums or other web applications, login is also pretty close to the same in every system out there. Although you've most likely done a bunch of hairy stuff like authenticating against LDAP, typekey, or passport, I think the majority of Rails newbies just want to get a password protected page up as quickly as possible so that they can get a demo application up and running as quickly as possible. The login generators available on the Rails wiki were confusing or broken, which probably left a number of people wondering both where to start, and why these things weren't working, when everything else in Rails seemed so easy. The simplest solution to the whole login dilemna would be to provide a good HOWTO on building a login system, and make this HOWTO easy to find on the rails wiki. This would satisfy 95% of the people who want to get a simple login system up and running, and the other 5% can continue arguing about it on their blogs. :) I was browsing the "Agile Web Development in Rails" book at the bookshop the other night, and it looks like there is a section describing a login system. Perhaps the authors of the book could simply make this section available as the free sample chapter. Or else just post somewhere publicly "if you need to build a login system, just see page 34 in the Agile Rails book."
Read more
Read less
Reply about 19 years ago
  Cancel

Leave a comment