Cerise provides user and group based access controls as well as an
API for accessing information about the current user. An existing
authorization and authentication system such as a database, directory
server, Kerberos, etc may be used by writing a custom
UserManager. Cerise comes with a simple implementation
that reads user information from a config file.
Cerise supports making certain request paths only accessible to a user or group, and can require authentication from a user that has not already been authenticated. If the user is not authorized to access a given path then an access denied page can be displayed. An example of this functionality is available at http://localhost:8000/examples/secure/user.ahtml if the server is running on the default port 8000.
The UserManager class controls user authentication and
authorization. A single server supports multiple
UserManagers, which are configured in
server.cfg. Each application can be
linked to one of the UserManagers via
app.cfg.
| method | description |
|---|---|
| initialize(server, params) |
initialize a new instance of the UserManager linked to
the supplied server and with the specified configuration parameters
|
| authenticate(username, token) |
attempt to authenticate a user with the supplied username and
token. This should return a new User object if
successful.
|
| authorized?(user, role) | check if the specified user is authorized to access a resource that is restricted to a specific role. |
The default UserManager implementation reads users from
cerise/cfg/user.cfg.
authenticate(username, token) checks if the specified
user exists and if the token is equal to the user's password.
authorized?(user, role) checks if the role is the user's
username or one of the groups the user belongs to.
The User class encapsulates information about a user. If
a user has been authenticated then the corresponding User
object is available in request.user
| method | description |
|---|---|
| initialize(username, token, groups) |
initialize a new instance of the User with the
supplied username, token, and groups
|
| member?(group) | check if the user is a member of the specified group |
| authenticate(token) | attempt to authenticate the user with the specified token |
Cerise can limit access to specific paths of an application via
the @secure_paths configuration item in
app.cfg. @secure_paths is
a hash of Regexp paths and String roles. When a request is made for a
a secure path, Cerise checks if the user is logged in and calls
UserManager.authorized?(user, role). If the user is not
logged in then the login page defined in @login_page will
be displayed.
Cerise provides two methods of authenticating a user: HTTP basic, and
form based. Both of these pass the username and password in clear
over the network, so a secure site should ensure that SSL is used. These
two methods correspond to the app.cfg
setting @auth_method which can have one of the following
values: :BASIC, :FORM.
Basic authentication allows the browser to prompt the user for a
username and password. After the user information is submitted,
it is passed to the HTTP server via the Authorization
header. Cerise will extract the username and password and attempt
to authenticate the user via the application's UserManager.
Form based authentication allows the application to provide a custom
login page for the user to view and submit. If the user is not yet
authenticated, Cerise redirects the user to a login page.
This page should submit the login details to a
Handler that authenticates the user via
request.user_manager. When Cerise redirects a
user to the login page, it sets the originally requested path in a
session variable named $original_path so that the login
handler can redirect the user back to the page they requested.
Cerise does not provide a default login handler
since the logic of a login tends to be very much application specific.
However there is an example handler in
cerise/apps/examples/content/login.rb that can be used by
other applications.