This padrino-auth provides the means to authenticate and authorize users. These modules are designed to be independent but compatible with each other.

Authentication means identifying the user by comparing provided parameters (usually login or email and password) with the credentials stored in the application database and selecting the matched one. This module provides a simple login form and related helpers methods including saving and restoring user location.

Make sure you have sessions enabled: enable :sessions.

If you use a different persistence storage you will have to make #session hash available to call in your app. Padrino::Login stores credentials id in session[settings.session_key]. You can customize session_key by calling set :session_key, :current_credentials_id. Default session_key name is "_login_#{app.app_name}".

By default Padrino::Login uses credentials model name Account. You can customize it by setting set :login_model, :user.

Usually a set of credentials are stored in application database. To access stored credentials Padrino::Login uses Account.authenticate class method. The Account model must provide this class method in at least two forms: authenticate with email/password, or with id. Account.authenticate is called

• with hash like { :email => 'user@example.com', :password => 'mypass' } to authenticate by email and password in response to user request
• with hash { :id => 42 } to restore credentials from session

To be able to access current credentials of the signed user your app will have to provide application helpers. By default Padrino::Login adds simple reader and writer with names credentials and credentials=(user). You can customize helper name by setting set :credentials_accessor, :visitor and you can override default accessor by defining your own reader and writer helpers with the said names.

• the reader is called before checking if the user is signed in
• the writer is called after authenticating user's credentials or restoring it from session

By default this option is disabled. To enable it you can call enable :login_bypass.

In development environment it sometimes is convenient to be able to bypass authentication. If you do this you also have to extend your model Account.authenticate class method to be able to return default credentials in response to hash { :bypass => true }. This way if the user authenticates with parameter bypass she will be assigned the credentials returned by you model and redirected to the stored location.

By default Padrino::Login registers a simple login controller for your app and binds it to /login.

To customize this url it you can call set :login_url, '/signin'. Also it's possible to disable registering the default controller by calling disable :login_controller. If you do so you should provide a controller for your custom login url which on request of authentication will call #authenticate helper. If the result is true it should call #restore_location, else it should show an error. Or you can do whatever you like, it's your controller after all.

Padrino::Login tries to inform Padrino::Access that /login url should be accessible for unauthenticated users by setting default set(:login_permissions) { set_access(:*, :allow => :*, :with => :login) }. Yes, it's a Proc and Padrino::Access tries to call it when registers itself.

If you name your controller another way you must redefine this. If you use another authorization solution you also should configure it to allow visiting /login url without having to authenticate.

To authenticate users Padrino::Login defines Sinatra before_filter which checks things and acts accordingly.

The first thing is if the user is already logged in. It uses the credentials reader we mentioned before, or tries to restore credentials from session.

The second thing is if the user is authorized to look at the requested page. To do so Padrino::Login calls #authorized? helper and checks it's bollean result. If this helper does not exist then your app is considered not requiring authorization. If it exists and responds with true then before_filter passes. If the helper exists and returns false then the user's location is saved and the user herself is redirected to login url.

#authorized? helper should be defined in your app if you want access control.

Call register Padrino::Login and you are ready to roll.

https://github.com/padrino/padrino-framework/wiki/Padrino-authorization-module

EXAMPLES.md