Authentification¶

Choisir un type d’Authentification¶

En général, vous aurez envie d’offrir l’authentification par formulaire. C’est le plus facile pour les utilisateurs utilisant un navigateur Web. Si vous construisez une API ou un service web, vous aurez peut-être à envisager l’utilisation de l’authentification de base ou l’authentification Digest. L’élément clé qui différencie l’authentification digest de l’authentification basic est la plupart du temps liée à la façon dont les mots de passe sont gérés. Avec l’authentification basic, le nom d’utilisateur et le mot de passe sont transmis en clair sur le serveur. Cela rend l’authentification de base non appropriée pour des applications sans SSL, puisque vous exposeriez sensiblement vos mots de passe. L’authentification Digest utilise un hachage condensé du nom d’utilisateur, mot de passe, et quelques autres détails. Cela rend l’authentification Digest plus approprié pour des applications sans cryptage SSL.

Vous pouvez également utiliser des systèmes d’authentification comme OpenID, mais openid ne fait pas parti du cœur de CakePHP.

Configuration des gestionnaires d’authentification¶

Vous configurez les gestionnaires d’authentification en utilisant $this->Auth->authenticate. Vous pouvez configurer un ou plusieurs gestionnaires pour l’authentification. L’utilisation de plusieurs gestionnaires d’authentification vous permet de supporter les différentes méthodes de connexion des utilisateurs. Quand les utilisateurs se connectent, les gestionnaires d’authentification sont utilisés dans l’ordre auquel ils ont été déclarés. Une fois qu’un gestionnaire est capable d’identifier un utilisateur, les autres gestionnaires ne seront pas utilisés. Inversement, vous pouvez mettre un terme à tous les authentifications en levant une exception.Vous pourrez traiter toutes les exceptions levées, et les gérer comme désiré.

Vous pouvez configurer le gestionnaire d’authentification dans les tableaux beforeFilter ou $components. Vous pouvez passer l’information de configuration dans chaque objet d’authentification en utilisant un tableau:

// Configuration de base
$this->Auth->authenticate = array('Form');

// Passer la configuration
$this->Auth->authenticate = array(
    'Basic' => array('userModel' => 'Membre'),
    'Form' => array('userModel' => 'Membre')
);

Dans le deuxième exemple vous pourrez noter que nous avons à déclarer la clé userModel deux fois. Pour vous aider à garder un code « propre », vous pouvez utiliser la clé all. Cette clé spéciale vous permet de définir les réglages qui sont passés à chaque objet attaché. La cle all est aussi utilisée comme cela AuthComponent::ALL:

// Passer la configuration en utilisant 'all'
$this->Auth->authenticate = array(
    AuthComponent::ALL => array('userModel' => 'Membre'),
    'Basic',
    'Form'
);

Dans l’exemple ci-dessus, à la fois Form et Basic prendront les paramétrages définis dans la clé « all ». Tous les paramètres transmis à un objet d’authentification particulier remplaceront la clé correspondante dans la clé “all”. Les objets d’authentification supportent les clés de configuration suivante.

• fields Les champs à utiliser pour identifier un utilisateur.

• userModel Le nom du model de l’utilisateur, par défaut User.

• scope Des conditions supplémentaires à utiliser lors de la recherche et l’authentification des utilisateurs, ex array('User.is_active' => 1).

• recursive La valeur de la clé récursive passé à find(). Par défaut à 0.

• contain options de Containable lorsque l’enregistrement de l’utilisateur est chargé. Si vous souhaitez utiliser cette option, vous devrez vous assurer que votre model a le behavior Containable attaché.

• passwordHasher Classe de hash de mot de passe. Par défaut à Simple.

  Nouveau dans la version 2.4.

• userFields La liste des champs à récupérer depuis le userModel. Cette option est utile lorsque vous avez une large table d’utilisateurs et que vous n’avez pas besoin de toutes les colonnes dans la session. Par défaut tous les champs sont récupérés.

  Nouveau dans la version 2.6.

  Configurer différents champs pour l’utilisateur dans le tableau $components:

  // Passer la configuration dans le tableau $components
  public $components = array(
      'Auth' => array(
          'authenticate' => array(
              'Form' => array(
                  'fields' => array('username' => 'email')
              )
          )
      )
  );
  

Ne mettez pas d’autre clés de configuration de Auth(comme authError, loginAction etc). Ils doivent se trouver au même niveau que la clé d’authentification. La configuration ci-dessus avec d’autres configurations ressemblerait à quelque chose comme.

// Passage de paramètre dans le tableau $components
public $components = array(
    'Auth' => array(
        'loginAction' => array(
            'controller' => 'users',
            'action' => 'login',
            'plugin' => 'users'
        ),
        'authError' => 'Pensiez-vous réellement que vous étiez autorisés à voir cela ?',
        'authenticate' => array(
            'Form' => array(
                'fields' => array(
                    'username' => 'mon_champ_username_personnalise', // 'username' par défaut
                    'password' => 'mon_champ_password_personnalise'  // 'password' par défaut
                )
            )
        )
    )
);

En plus de la configuration courante, l’authentification de base prend en charge les clés suivantes:

• realm Le domaine en cours d’authentification. Par défaut à env('SERVER_NAME').

En plus de la configuration courante, l’authentification Digest prend en charge les clés suivantes:

• realm Le domaine en cours d’authentification. Par défaut à servername

• nonce Un nonce utiliser pour l’authentification. Par défaut à uniqid().

• qop Par défaut à auth, pas d’autre valeur supportée pour le moment.

• opaque Une chaîne qui doit être retourné à l’identique par les clients. Par Défaut à md5($settings['realm']).

Identifier les utilisateurs et les connecter¶

Par le passé le component Auth AuthComponent connectait les utilisateurs automatiquement. C’était un peu déroutant pour certain, et rendait la création au travers du component Auth AuthComponent par moment un peu difficile. Avec la version 2.0, vous avez besoin d’appeler manuellement $this->Auth->login() pour connecter un utilisateur.

Quand les utilisateurs s’identifient, les objets d’identification sont vérifiés dans l’ordre où ils ont été attachés. Une fois qu’un objet peut identifier un utilisateur, les autres objets ne sont pas vérifiés. Une simple fonction de connexion pourrait ressembler à cela

public function login() {
    if ($this->request->is('post')) {
        // Important: Utilisez login() sans argument! Voir warning ci-dessous.
        if ($this->Auth->login()) {
            return $this->redirect($this->Auth->redirectUrl());
            // Avant 2.3, utilisez
            // `return $this->redirect($this->Auth->redirect());`
        }
        $this->Flash->error(
            __('Username ou password incorrect')
        );
        // Avant 2.7, utilisez
        // $this->Session->setFlash(__('Username ou password incorrect'));
    }
}

Le code ci-dessus (sans aucune donnée transmise à la méthode login), tentera de connecter un utilisateur en utilisant les données POST, et sera redirigé en cas de succès sur la dernière page visitée, ou AuthComponent::$loginRedirect. Si le login est en échec, un message flash est défini.

Créer des objets d’authentification personnalisés¶

Comme les objets d’authentification sont modulaires, vous pouvez créer des objets d’authentification personnalisés pour votre application ou plugins. Si par exemple vous vouliez créer un objet d’authentification OpenID. Dans app/Controller/Component/Auth/OpenidAuthenticate.php vous pourriez mettre ce qui suit:

App::uses('BaseAuthenticate', 'Controller/Component/Auth');

class OpenidAuthenticate extends BaseAuthenticate {
    public function authenticate(CakeRequest $request, CakeResponse $response) {
        // Faire les trucs d'OpenID ici.
        // Retourne un tableau de l\'user si ils peuvent authentifier
        // l\'user
        // retourne false dans le cas contraire
    }
}

Les objets d’authentification devraient retourner false si ils ne peuvent identifier l’utilisateur. Et un tableau d’information utilisateur si ils le peuvent.Il n’est pas utile d’étendre (extend) BaseAuthenticate, simplement votre objet d’identification doit implémenter la méthode authenticate(). La class BaseAuthenticate fournie un nombre de méthode très utiles communément utilisées. Vous pouvez aussi implémenter une méthode getUser() si votre objet d’identification doit supporter des authentifications sans cookie ou sans état (stateless). Regardez les sections portant sur l’authentification digest et basic plus bas pour plus d’information.

Utilisation d’objets d’authentification personnalisés¶

Une fois votre objet d’authentification créer, vous pouvez les utiliser en les incluant dans le tableau d’authentification AuthComponents:

$this->Auth->authenticate = array(
    'Openid', // objet d'authentification app
    'AuthBag.Combo', // plugin objet d'identification.
);

Création de systèmes d’authentification stateless¶

Les objets d’authentification peuvent implémenter une méthode getUser() qui peut être utilisée pour supporter les systèmes de connexion des utilisateurs qui ne reposent pas sur les cookies. Une méthode getUser typique regarde l’environnement de la requête (request/environnement) et y utilise les informations d’identification de l’utilisateur. L’authentification HTTP Basic utilise par exemple $_SERVER['PHP_AUTH_USER'] et $_SERVER['PHP_AUTH_PW'] pour les champs username et password. Pour chaque requête, si un client ne supporte pas les cookies, ces valeurs sont utilisées pour ré-identifier l’utilisateur et s’assurer que c’est un utilisateur valide. Comme avec les méthodes d’authentification de l’objet authenticate(), la méthode getuser() devrait retourner un tableau d’information utilisateur en cas de succès, et false en cas d’echec.

public function getUser($request) {
    $username = env('PHP_AUTH_USER');
    $pass = env('PHP_AUTH_PW');

    if (empty($username) || empty($pass)) {
        return false;
    }
    return $this->_findUser($username, $pass);
}

Le contenu ci-dessus montre comment vous pourriez mettre en œuvre la méthode getUser pour les authentifications HTTP Basic. La méthode _findUser() fait partie de BaseAuthenticate et identifie un utilisateur en se basant sur un nom d’utilisateur et un mot de passe.

Gestion des requêtes non authentifiées¶

Quand un user non authentifié essaie d’accéder à une page protégée en premier, la méthode unauthenticated() du dernier authenticator dans la chaîne est appelée. L’objet d’authentification peut gérer la réponse d’envoi ou la redirection appropriée et retourne true pour indiquer qu’aucune action suivante n’est nécessaire. Du fait de l’ordre dans lequel vous spécifiez l’objet d’authentification dans les propriétés de AuthComponent::$authenticate.

Si authenticator retourne null, AuthComponent redirige l’user vers l’action login. Si c’est une requête ajax et AuthComponent::$ajaxLogin est spécifiée, cet element est rendu, sinon un code de statut HTTP 403 est retourné.

Afficher les messages flash de Auth¶

Pour afficher les messages d’erreur de session que Auth génère, vous devez ajouter les lignes de code suivante dans votre layout. Ajoutez les deux lignes suivantes au fichier app/View/Layouts/default.ctp dans la section body de préférence avant la ligne content_for_layout:

// CakePHP 2.7+
echo $this->Flash->render();
echo $this->Flash->render('auth');

// Avant 2.7
echo $this->Session->flash();
echo $this->Session->flash('auth');

Vous pouvez personnaliser les messages d’erreur, et les réglages que le component Auth AuthComponent utilise. En utilisant $this->Auth->flash vous pouvez configurer les paramètres que le component Auth utilise pour envoyer des messages flash. Les clés disponibles sont :

• element - L’élément à utiliser , “default” par défaut.

• key - La clé a utiliser , “auth” par défaut

• params - Le tableau des paramètres additionnels à utiliser, array() par défaut

En plus des paramètres de message flash, vous pouvez personnaliser d’autres messages d’erreurs que le component AuthComponent utilise. Dans la partie beforeFilter de votre controller, ou dans le paramétrage du component vous pouvez utiliser authError pour personnaliser l’erreur à utiliser quand l’authentification échoue

$this->Auth->authError = "Cette erreur se présente à l'utilisateur qui tente d'accéder à une partie du site qui est protégé.";

Dans le beforeFilter() de votre controller, ou les configurations du component:

if (!$this->Auth->loggedIn()) {
    $this->Auth->authError = false;
}

Hachage des mots de passe¶

Le component Auth ne fait fait plus automatiquement le hachage de tous les mots de passe qu’il rencontre. Ceci à été enlevé parce qu’il rendait un certain nombre de tâches communes comme la validation difficile. Vous ne devriez jamais stocker un mot de passe en clair, et avant de sauvegarder un utilisateur vous devez toujours hacher le mot de passe.

Depuis 2.4, la génération et la vérification des hashs de mot de passe a été déléguée à des classes de hasher de mot de passe. Les objets d’authentification utilisent un nouveau paramètre passwordHasher qui spécifie la classe de hasher de mot de passe à utiliser. Cela peut être une chaîne en spécifiant un nom de classe ou un tableau avec la clé className faisant état du nom de la classe et toutes autres clés supplémentaires seront passées au constructeur de hasher de mot de passe en configuration. Le classe de hasher par défaut Simple peut être utilisée pour le hashage sha1, sha256, md5. Par défaut, le type de hash défini dans la classe Security sera utilisé. Vous pouvez utiliser un type de hash spécifique comme ceci:

public $components = array(
    'Auth' => array(
        'authenticate' => array(
            'Form' => array(
                'passwordHasher' => array(
                    'className' => 'Simple',
                    'hashType' => 'sha256'
                )
            )
        )
    )
);

Lors de la création de nouveaux enregistrements d’utilisateurs, vous pouvez hasher un mot de passe dans le callback beforeSave de votre model en utilisant la classe de hasher de mot de passe appropriée:

App::uses('SimplePasswordHasher', 'Controller/Component/Auth');

class User extends AppModel {
    public function beforeSave($options = array()) {
        if (!empty($this->data[$this->alias]['password'])) {
            $passwordHasher = new SimplePasswordHasher(array('hashType' => 'sha256'));
            $this->data[$this->alias]['password'] = $passwordHasher->hash(
                $this->data[$this->alias]['password']
            );
        }
        return true;
    }
}

Vous n’avez pas besoin de hacher le mot de passe avant d’appeler $this->Auth->login(). Les différents objets d’authentification hacherons les mots de passe individuellement.

Utiliser bcrypt pour les mots de passe¶

Dans CakePHP 2.3, la classe BlowfishAuthenticate a été introduite pour permettre l’utilisation de bcrypt c’est-à-dire Blowfish pour les mots de passe hashés. Les hashes Bcrypt sont plus difficiles à forcer sauvagement par rapport aux mots de passe stockés avec sha1. Mais BlowfishAuthenticate a été déprécié dans 2.4 et à la place BlowfishPasswordHasher a été ajoutée.

Un hasher de mot de passe blowfish peut être utilisé avec toute classe d’authentification. Tout ce que vous avez à faire est de spécifier la configuration passwordHasher pour l’objet d’authentification:

public $components = array(
    'Auth' => array(
        'authenticate' => array(
            'Form' => array(
                'passwordHasher' => 'Blowfish'
            )
        )
    )
);

App::uses('DigestAuthenticate', 'Controller/Component/Auth');

class User extends AppModel {
    public function beforeSave($options = array()) {
        // fabrique un mot de passe pour l'auth Digest.
        $this->data[$this->alias]['digest_hash'] = DigestAuthenticate::password(
            $this->data[$this->alias]['username'], $this->data[$this->alias]['password'], env('SERVER_NAME')
        );
        return true;
    }
}

Création de classes de hachage de mots de passe personnalisées¶

Les classes de hachage de mots de passe personnalisées doivent étendre la classe AbstractPasswordHasher et implémenter les méthodes abstraites hash() et check(). Dans app/Controller/Component/Auth/CustomPasswordHasher.php, vous pourriez mettre ceci:

App::uses('AbstractPasswordHasher', 'Controller/Component/Auth');

class CustomPasswordHasher extends AbstractPasswordHasher {
    public function hash($password) {
        // choses ici
    }

    public function check($password, $hashedPassword) {
        // choses ici
    }
}

Connecter les utilisateurs manuellement¶

Parfois, le besoin se fait sentir de connecter un utilisateur manuellement, par exemple juste après qu’il se soit enregistré dans votre application. Vous pouvez faire cela en appelant $this->Auth->login() avec les données utilisateur que vous voulez pour la “connexion”:

public function register() {
    if ($this->User->save($this->request->data)) {
        $id = $this->User->id;
        $this->request->data['User'] = array_merge(
            $this->request->data['User'],
            array('id' => $id)
        );
        unset($this->request->data['User']['password']);
        $this->Auth->login($this->request->data['User']);
        return $this->redirect('/users/home');
    }
}

Accéder à l’utilisateur connecté¶

Une fois que l’utilisateur est connecté, vous avez souvent besoin d’informations particulières à propos de l’utilisateur courant. Vous pouvez accéder à ce dernier en utilisant AuthComponent::user(). Cette méthode est statique, et peut être utilisée globalement après le chargement du component Auth. Vous pouvez y accéder à la fois avec une méthode d’instance ou une méthode statique:

// Utilisez n'importe où
AuthComponent::user('id')

// Depuis l'intérieur du controler
$this->Auth->user('id');

Déconnexion des utilisateurs¶

Éventuellement vous aurez besoin d’un moyen rapide pour dés-authentifier les utilisateurs et les rediriger où ils devraient aller. Cette méthode est aussi très pratique si vous voulez fournir un lien “Déconnecte-moi” à l’intérieur de la zone membres de votre application:

public function logout() {
    $this->redirect($this->Auth->logout());
}

La déconnexion des utilisateurs connectés avec l’authentification Basic ou Digest est difficile à accomplir pour tous les clients. La plupart des navigateurs retiennent les autorisations pendant qu’il restent ouvert. Certains navigateurs peuvent être forcés en envoyant un code 401. Le changement du realm de l’authentification est une autre solution qui fonctionne pour certain clients.

Configurer les gestionnaires d’autorisation¶

Vous configurez les gestionnaires d’autorisations via $this->Auth->authorize. Vous pouvez configurer un ou plusieurs gestionnaires. L’utilisation de plusieurs gestionnaires vous donne la possibilité d’utiliser plusieurs moyens de vérifier les autorisations. Quand les gestionnaires d’autorisation sont vérifiés, ils sont appelés dans l’ordre dans lequel ils sont déclarés. Les gestionnaires devraient retourner false s’ils ne sont pas capables de vérifier les autorisations, ou bien si la vérification a échoué. Ils devraient retourner true s’ils sont capables de vérifier correctement les autorisations. Les gestionnaires seront appelés dans l’ordre jusqu’à ce que l’un d’entre eux retourne true. Si toutes les vérifications échouent, l’utilisateur sera redirigé vers la page d’où il vient. Vous pouvez également stopper les autorisations en levant une exception. Vous aurez besoin de traiter toutes les exceptions levées, et de les manipuler.

Vous pouvez configurer les gestionnaires d’autorisations dans le beforeFilter de votre controller ou dans le tableau $components. Vous pouvez passer les informations de configuration dans chaque objet d’autorisation, en utilisant un tableau:

// paramétrage Basique
$this->Auth->authorize = array('Controller');

// passage de paramètre
$this->Auth->authorize = array(
    'Actions' => array('actionPath' => 'controllers/'),
    'Controller'
);

Tout comme Auth->authenticate, Auth->authorize vous aident à garder un code propre, en utilisant la clé all. Cette clé spéciale vous aide à définir les paramètres qui sont passés à chaque objet attaché. La clé all est aussi exposée comme AuthComponent::ALL:

// passage de paramètre en utilisant 'all'
$this->Auth->authorize = array(
    AuthComponent::ALL => array('actionPath' => 'controllers/'),
    'Action',
    'Controller'
);

Dans l’exemple ci-dessus, à la fois l”Action et le Controller auront les paramètres définis pour la clé “all”. Chaque paramètre passé à un objet d’autorisation spécifique remplacera la clé correspondante dans la clé “all”. Le noyau authorize objects supporte les clés de configuration suivantes.

• actionPath Utilisé par ActionsAuthorize pour localiser le controller action ACO’s dans l’arborescence ACO.

• actionMap Action -> CRUD mappings. Utilisé par CrudAuthorize et les objets d’autorisation qui veulent mapper les actions aux rôles CRUD.

• userModel Le nom du nœud ARO/Model dans lequel l’information utilisateur peut être trouvé. Utilisé avec ActionsAuthorize.

Création d’objets Authorize personnalisés¶

Parce que les objets authorize sont modulables, vous pouvez créer des objets authorize personnalisés dans votre application, ou plugins. Si par exemple vous voulez créer un objet authorize LDAP. Dans app/Controller/Component/Auth/LdapAuthorize.php, vous pourriez mettre cela:

App::uses('BaseAuthorize', 'Controller/Component/Auth');

class LdapAuthorize extends BaseAuthorize {
    public function authorize($user, CakeRequest $request) {
        // Faire les trucs pour le LDAP ici.
    }
}

L’objet Authorize devrait retourner false si l’utilisateur se voit refuser l’accès, ou si l’objet est incapable de faire un contrôle. Si l’objet est capable de vérifier les accès de l’utilisateur, true devrait être retourné. Ça n’est pas nécessaire d’étendre BaseAuthorize, il faut simplement que votre objet authorize implémente la méthode authorize(). La classe BaseAuthorize fournit un nombre intéressant de méthodes utiles qui sont communément utilisées.

$this->Auth->authorize = array(
    'Ldap', // objet app authorize .
    'AuthBag.Combo', // objet authorize du plugin.
);

Ne pas utiliser d’autorisation¶

Si vous souhaitez ne pas utiliser les objets d’autorisation intégrés, et que vous voulez gérer les choses entièrement à l’extérieur du Component Auth (AuthComponent) vous pouvez définir $this->Auth->authorize = false;. Par défaut le component Auth démarre avec authorize = false. Si vous n’utilisez pas de schéma d’autorisation, assurez-vous de vérifier les autorisations vous-même dans la partie beforeFilter de votre controller ou avec un autre component.

Rendre des actions publiques¶

Il y a souvent des actions de controller que vous souhaitez laisser entièrement publiques, ou qui ne nécessitent pas de connexion utilisateur. Le component Auth (AuthComponnent) est pessimiste, et par défaut interdit l’accès. Vous pouvez marquer des actions comme publique en utilisant AuthComponent::allow(). En marquant les actions comme publique, le component Auth ne vérifiera pas la connexion d’un utilisateur, ni n’autorisera la vérification des objets:

// Permet toutes les actions. CakePHP 2.0 (déprécié)
$this->Auth->allow('*');

// Permet toutes les actions. CakePHP 2.1 et plus
$this->Auth->allow();

// Ne permet que les actions view et index.
$this->Auth->allow('view', 'index');

// Ne permet que les actions view et index.
$this->Auth->allow(array('view', 'index'));

Vous pouvez fournir autant de nom d’action dont vous avez besoin à allow(). Vous pouvez aussi fournir un tableau contenant tous les noms d’action.

Fabriquer des actions qui requièrent des autorisations¶

Par défaut, toutes les actions nécessitent une authorisation. Cependant, si après avoir rendu les actions publiques, vous voulez révoquer les accès publics. Vous pouvez le faire en utilisant AuthComponent::deny():

// retire une action
$this->Auth->deny('add');

// retire toutes les actions .
$this->Auth->deny();

// retire un groupe d'actions.
$this->Auth->deny('add', 'edit');
$this->Auth->deny(array('add', 'edit'));

Vous pouvez fournir autant de noms d’action que vous voulez à deny(). Vous pouvez aussi fournir un tableau contenant tous les noms d’action.

Utilisation de ControllerAuthorize¶

ControllerAuthorize vous permet de gérer les vérifications d’autorisation dans le callback d’un controller. C’est parfait quand vous avez des autorisations très simples, ou que vous voulez utiliser une combinaison models + components à faire pour vos autorisations, et ne voulez pas créer un objet authorize personnalisé.

Le callback est toujours appelé isAuthorized() et devrait retourner un booléen pour indiquer si l’utilisateur est autorisé ou pas à accéder aux ressources de la requête. Le callback est passé à l’utilisateur actif, il peut donc être vérifié:

class AppController extends Controller {
    public $components = array(
        'Auth' => array('authorize' => 'Controller'),
    );
    public function isAuthorized($user = null) {
        // Chacun des utilisateur enregistré peut accéder aux fonctions publiques
        if (empty($this->request->params['admin'])) {
            return true;
        }

        // Seulement les administrateurs peuvent accéder aux fonctions d'administration
        if (isset($this->request->params['admin'])) {
            return (bool)($user['role'] === 'admin');
        }

        // Par défaut n'autorise pas
        return false;
    }
}

Le callback ci-dessus fournirait un système d’autorisation très simple où seuls les utilisateurs ayant le rôle d’administrateur pourraient accéder aux actions qui ont le préfixe admin.

Utilisation de ActionsAuthorize¶

ActionsAuthorize s’intègre au component ACL, et fournit une vérification ACL très fine pour chaque requête. ActionsAuthorize est souvent jumelé avec DbAcl pour apporter un système de permissions dynamique et flexible qui peuvent être éditées par les utilisateurs administrateurs au travers de l’application. Il peut en outre être combiné avec d’autres implémentations Acl comme IniAcl et des applications Acl backends personnalisées.

Utilisation de CrudAuthorize¶

CrudAuthorize s’intègre au component Acl, et fournit la possibilité de mapper les requêtes aux opérations CRUD. Fournit la possibilité d’autoriser l’utilisation du mapping CRUD. Les résultats mappés sont alors vérifiés dans le component Acl comme des permissions spécifiques.

Par exemple, en prenant la requête /posts/index. Le mapping par défaut pour index est une vérification de la permission de read. La vérification d’Acl se ferait alors avec les permissions de read pour le controller posts. Ceci vous permet de créer un système de permission qui met d’avantage l’accent sur ce qui est en train d’être fait aux ressources, plutôt que sur l’action spécifique en cours de visite.

Mapper les actions en utilisant CrudAuthorize¶

Quand vous utilisez CrudAuthorize ou d’autres objets authorize qui utilisent le mapping d’action, il peut être nécessaire de mapper des méthodes supplémentaires. vous pouvez mapper des actions –> CRUD permissions en utilisant mapAction(). En l’appelant dans le component Auth vous déléguerez toutes les actions aux objets authorize configurés, ainsi vous pouvez être sûr que le paramétrage sera appliqué partout:

$this->Auth->mapActions(array(
    'create' => array('register'),
    'view' => array('show', 'display')
));

La clé pour mapActions devra être les permissions CRUD que vous voulez définir, tandis que les valeurs devront être un tableau de toutes les actions qui sont mappées vers les permissions CRUD.