NAME¶
Jifty::Manual::AccessControl - Using Jifty's default ACL system
DESCRIPTION¶
Out of the box Jifty-based applications have an ACL system. The system
automatically validates ACLs on Jifty::Record objects by calling the method
"current_user_can" before any create, read, update, or delete
operation. In all cases, the arguments passed to the CRUD operation are passed
as extra arguments to "current_user_can".
On "create()", we reject the operation if
"current_user_can('create')" returns FALSE.
On "_value()" or "
somefieldname", we reject the
operation if "current_user_can('read')" returns false.
On "_set()" or "
set_somefieldname", we reject the
operation if "current_user_can('update')" returns false.
On "delete()", we reject the operation if
"current_user_can('delete')" returns false.
Out of the box, "current_user_can" returns 1. When you want to
actually check ACLs, you'll need to override "current_user_can()" in
your "Jifty::Record" subclass.
It's likely that at some point, you'll decide you want to ask other questions on
certain types of operations. Say, you only want to let administrators update
the "paid_account" field. In that case, you'd override
"check_update_rights()" to look for the "admin" right
rather than the "update" right, if the "FIELD" is
"paid_account".
ENABLING ACCESS CONTROL USING THE USER PLUGIN¶
To painlessly enable the AccessControl subsystem, a User plugin is available
with an authentication plugin, the "Authentication::Password" plugin
may get enabled. This is done in the
etc/config.yml configuration file.
Plugins:
- Authentication::Password: {}
Then, create an "App::Model::User" class that will be override with
"Jifty::Plugin::User::Mixin::Model::User" and an authentication
plugin "Jifty::Plugin::Authentication::Password::Mixin::Model::User"
, for example:
use strict;
use warnings;
package App::Model::User;
use Jifty::DBI::Schema;
use App::Record schema {
};
use Jifty::Plugin::User::Mixin::Model::User;
use Jifty::Plugin::Authentication::Password::Mixin::Model::User;
# Your model-specific methods go here.
1;
Next, create the table in your database using the
jifty executable like
"./bin/jifty schema --setup".
Expanding the Model¶
The model that manages "User" Records is not limited to the plugin's
definition. It can be expanded by providing an additional schema definition.
Every column here will be added to the plugin's columns. Simply add a schema
definition block like this:
use Jifty::DBI::Schema;
use App::Record schema {
column 'extra_column_name';
column 'mygroup' =>
valid_values are qw/admin moderator user/,
default is 'user';
# more columns if necessary
};
The full syntax for defining a schema can be found in Jifty::Manual::Models or
in Jifty::DBI::Schema.
If you want to manage an admin group, you must protect the group column as only
a superuser can change it. Then, you override "current_user_can" in
"App::Model::User"
sub current_user_can {
my $self = shift;
my $type = shift;
my %args = (@_);
return 0
if ( $type eq 'update'
and !$self->current_user->is_superuser
and $args{'column'} eq 'mygroup' );
return 1;
}
Defining a method "_init" in your "App::CurrentUser" class
gives you a chance to add more data to the "CurrentUser" object.
This method will automatically get called after the Plugin's "_init"
is done.
package App::CurrentUser;
use strict;
use warnings;
use base qw(Jifty::CurrentUser);
__PACKAGE__->mk_accessors(qw(group));
sub _init {
my $self = shift;
my %args = (@_);
if (keys %args) {
$self->user_object(App::Model::User->new(current_user => $self));
$self->user_object->load_by_cols(%args);
if ( $self->user_object->mygroup eq 'admin') {
$self->is_superuser(1);
};
$self->group($self->user_object->mygroup);
};
$self->SUPER::_init(%args);
};
With your "App::CurrentUser", users in group admin are superuser and
you can use "Jifty->web->current_user->group" in your
application.
Templates defined by the "Authentication::Password"
plugin¶
To avoid the need for repetitive work, the "Authentication::Password"
plugin already defines a couple of usable templates:
- /login
- provides a login screen with a signup option. After
successful login, the current continuation is called. If no continuation
exists, the template sitting at the base URL ( /) is called.
- /logout
- logs out the current user.
- /signup
- allows a user to sign up himself/herself. By default a
confirmation mail is sent out that has to get followed by the user.
- /passwordreminder
- after entering his/her mail address, the user will receive
a mail that contains a link to /let/reset_lost_password.
- /let/confirm_email
- is called in the mail and results in accepting the
user.
- /let/reset_lost_password
- enabled by the /passwordreminder template, this
template allows a user to reenter a password for future use.
Doing checks at other places in your code¶
If you need to check more than Model-based record operations you will have to do
some coding on your own. "Jifty->web->current_user" provides a
"App::CurrentUser" object that can get queried about the current
user. This object provides some convenience methods:
- "username"
- returns the name of the current user or "undef"
if not logged in.
- "id"
- returns the id of the current user or "undef" if
not logged in.
SEE ALSO¶
Jifty::CurrentUser, Jifty::Record, Jifty::RightsFrom,
Jifty::Plugin::Authentication::Ldap, Jifty::Plugin::Authentication::CAS