---
name: "Jifty::Manual::AccessControl"
section: "3pm"
platform: "linux"
package: "libjifty-perl"
version: "1.10518+dfsg-2"
release: "Debian 7 (Wheezy)"
platforms: ["linux"]
url: "https://new.carta.tech/Jifty::Manual::AccessControl"
---

# Jifty::Manual::AccessControl(3pm)

Using Jifty's default ACL system

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