Handle account management for Sinatra web-app
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.




accounts is a website plug-in that offers than the basic user-account management and authentication features that many sites need.


Most sites I've built require a user authentication and user-account management features. These include:

  • Registering a new user
  • Authenticating (logging-on)
  • Verifying a user's e-mail
  • Modifying a user's e-mail
  • Resetting a user's password
  • Suspending a user's account

I would much rather delegate these features to an OpenID/Oauth service, In other words, let a user authenticate to a third party that we both trust (at least for the purpose we're using them for here) such as Yahoo or Facebook or Google who will then present a token to my client's site representing that the user has been authenticated.

Nevertheless, many of my clients and prospective clients have insisted that their sites manage these features without requiring their customers to authenticate through a third party.

So I'm left again reinventing the same old authentication and account-management features every time. The pages look different and the details may be slightly different each time

  • some sites want to know their subscribers' full name, home address and phone number, others just want an e-mail - but the features and use-cases are nearly identical.


accounts is a website plug-in that offers than the basic user-account management and authentication features that many sites need.

Accounts::Server defines the following paths for your web-app:

  • POST '/logon'
  • POST '/register'
  • POST '/forgot-password'
  • POST '/change-password'
  • POST '/change-email'

Your app must provide the pages and forms that will post to these paths. See demo/web_app.rb for example of usage. That file could be your template for a new web-app that uses the accounts gem.

accounts supports a very lean and minimal user-registration protocol.

  1. A user who wants to register need only submit a valid e-mail address.
  2. The service will attempt to e-mail a unique URI to the address they have given.
  3. When the new registree candidate visits that URI (presumably by clicking), that e-mail (and their identity) may be considered as valid.
  4. The new registree is then invited to create and verify a password.

This and other use cases are described in the Cucumber features documents and behavioral tests.

accounts makes a few assumptions:

  1. Each subscriber to a site can be uniquely identified by whatever e-mail address he submits.
  2. Password privacy depends on the transport layer (SSL).
  3. Personal contact info and other attributes of a subscriber are kept in a separate resource than Account that can be joined with Account.
  4. Users may change their e-mail address, thus changing their primary identity.
    This is justified because people do change their e-mail address from time to time and should not have to re-register with a new identity. Changing their e-mail will not break associations to other tables you have defined through account_id.


See lib/accounts/configure.rb for list of configurable options and for example of how to set them in order to customize the pages and e-mails for your app.

Accounts defines several tables for keeping track of user accounts. These do not include any personal or contact info other than a person's e-mail address. If your app needs to maintain other info about it's subscribers, you can create a separate table and join it with Accounts::Account defined in lib/accounts/model.rb in a one-to-one relationship.

Accounts is agnostic about what templating engine engine your app uses, as it does not use one itself, but merely outputs shorts strings as responses that you may customize by replacing them with your own strings or with Procs that use a template engine.

Accounts is agnostic about what mail engine engine your app uses, although the default configuration uses http://github.com/mikel/mail. If you wish to use a different mail engine, you may do so in the Proc objects you provide to Accounts::configure.


Can't get sinatra-reloader to work since I converted it into a modular app.


This package and all its contents are provided provided AS-IS, for demonstration purposes. Lawrence Siden and Westside Consulting LLC make no warranty about this package's security, correctness or fitness for commercial use.