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...

Yesterday, DHH said:

“I’d love for Rails to be easy as pie to run in a shared hosting environment, though. I’d love for Rails to be easy as pie to run in any environment. In that ‘more people could have fun learning Rails and deploying their first hobby application’ kind of way.”

We humbly suggest that Heroku is one possible solution to the latter part of statement. Our vision for the long term is much grander than just a learning/hobby tool; but our beta product, as it stands today, can already fill this need quite nicely.

RSpec 1.1 is now a part of the default plugin kit for Heroku apps.

We've been fans of RSpec for a while now, and feel that it represents the future of TDD/BDD for the Rails world. If you're not familiar with RSpec, read up and then give it a try.

You don't need to install anything to use RSpec in your Heroku app, but you do need to initialize the spec/ and stories/ directories by running the rspec generator. Just open the Generate dialog, type in rspec, and click Run.

Once you've written some specs, you can run them the usual way: open a rake console and type spec. You can still run your Test::Unit tests with the test command, or you can run tests followed by spec with default.

Don't worry, support for Test::Unit won't be going away any time soon - but we do encourage you to consider RSpec the next time you create a new model. Use the generate command rspec_model instead of the usual model to get a blank spec created for you. Or, use rspec_model <model_name> against an existing model and it will generate the spec (in spec/models) without overwriting the existing model or migration.

Rails 1.2 is now officially deprecated for Heroku apps. Starting January 3 (that’s tomorrow), new features we are developing will not be available on apps still configured to use Rails 1.2. Then, on January 21, we will automatically upgrade any remaining 1.2 apps.

We know it’s only been a month since Rails 2 came out, so we hope this doesn’t come across as overly harsh. By taking this approach we can spend less time backporting, which means more time for new features. Since Heroku is still in early beta we feel that this is reasonable. Rest assured that when the next major Rails release comes around, we’ll be committed to supporting 2.0 for a much longer time window.

In most cases, upgrading should be as easy as changing your `config/environment.rb` to contain 2.0.2 instead of 1.2.x, and adding a block that looks like this to your initializer:

If you find that you have breakage after the upgrade, read this post by Steve Ross which covers potential areas of incompatibility in detail.

And if you’re still having difficulty with the upgrade, just send us an email with the name of your app and we’ll be happy to help.

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.