Easy Authentication

Backstory: A Fiery Debate

Writing a user model and the standard login authentication code seems like busywork to a lot of coders. In fact, many people expected a next-generation app framework such as Rails to handle this for you. After all, Django does. Initially the login engine for Rails seemed to fill this slot, but following a fair amount of controversy over best practices, the login engine was killed by its creator.

With our BDfL having forever cursed prebuilt login systems, the Rails community mostly stopped trying to make them. Yet, this puts us back at square one: developers are annoyed at the amount of boilerplate busywork that is necessary for almost every web app they write.

acts_as_authencated is the halfway solution that is now popular: it’s a generator, not a drop-in component, so it spits out the boilerplate for you, and then you can modify it. And then of course there’s the idea that logins shouldn’t be maintained by individual sites at all, but stored someplace in the ownership of users. OpenID is the great hope here, but while we wait for this technology to mature (and gain acceptance with less technical audiences), maintaining user logins will continue to be a part of building web apps.

The debate over how to create login authentication will continue to smoulder for some time yet. But in the meantime, Heroku now offers a user login solution that will be handy for apps shared with a small number of people, and requires almost no code.

Heroku Users

Apps created on Heroku are already shared with some number of users, specified by their email addresses (this works the same as other types of collaborative editing apps, such as Google Docs). Since these users are already logging in to access the app, wouldn’t it be handy if you could find out from the Heroku backend who was logged into your app?

We thought so too. Which why we’ve created the heroku_user helper object. It’s a small feature, but a surprisingly convenient one. I’ve already found it quite useful in some of my own personal apps. Our company wiki, for example, uses this method. So how does it work?

Read more →

View-Only Users

There are now two access levels for collaborators on Heroku apps:

  • Full edit access, which allows access to everything: editing code, importing or exporting the database, changing the settings, etc.
  • View-only access, which allows the user to view the app only. That is, they can visit the app url (myapp.heroku.com) but not any of the settings pages or the edit url (edit.myapp.heroku.com).

For example, a client who wants to use the app but neither needs nor wants access to the code could be set as a view-only user.

If your app sharing is set to public, the view-only access level has no use.

Do note that these settings have no effect on users changing your app’s data through the normal web front-end. For example, if you have a scaffold page that doesn’t perform any authentication, a view-only user can create, update, and delete records. When we say “full edit access” we’re referring to editing code. What happens when the user views your app is up to you.

Browse the blog archives, subscribe to the full-text feed, or visit the engineering blog.