Comment puis-je rafraichir le cache de mes données d'authentification

Bonjour,

Lorsque tu mets à jour ton profil, tu sauvegardes en base?

Il faut aussi mettre à jour la session.. Ce n'est pas du cache.

cordialement

Antho

Salut Antho,
Ben oui, mais je en vois pas comment le faire.
Es-ce que AuthComponent::user('') est un array?

Es-ce que le fait de faire

AuthComponment::user() = $this->User->find('first', array('conditions'=>array('id'=>$id)));

suffit?

Merci

Bonjour.
AuthComponent contient les données contenues dans la session.
Tu peux par exemple faire :

AuthComponent::user('username');

static AuthComponent::user($key = null)¶
Paramètres: 
$key (string) – La clé des données utilisateur que vous voulez récupérer.Si elle est null, tous les utilisateurs seront retournés. Peut aussi être appelée comme une instance de méthode.
Prend les données concernant de l’utilisateur connecté, vous pouvez utiliser une clé propriétaire pour appeler une donnée spécifique à propos d’un utilisateur:
$id = $this->Auth->user('id');
Si l’utilisateur courant n’est pas connecté ou que la clé n’existe pas null sera retourné.

Il faut penser à regarder le book de CakePHP de temps en temps.

Ha ben oui, ca j'avais bien compris.
Le problème que j'ai c'est que lorsque je change des informations de mon profile et que je sauve ces changements dans ma base de donnée (par exemple, mon prénom), l'enregistrement se fait bien, mais

AuthComponent::user('firstname');

affichera l'ancienne valeur, sauf si je me délog et me relog.

Je voulais éviter qu'on ait besoin de se deloger, c'est pourquoi je me demandais s'il était possible de remplacer les valeurs (ou une valeur) stocké dans

AuthComponent::user();

Voili voila

Peut-être qu'en utilisant

$this->Session->delete('User');

après la modification des données de la table, tu arriveras à faire ce que tu as besoin.
Je ne peux pas te le certifier vu que je ne l'ai pas testé, mais dans tous les cas, ça ne détruit pas la session, ça devrait donc te permettre de rafraîchir les données de la session concernant les informations de l'utilisateur.

Bonsoir, essaye un truc comme ça après ta sauvegarde:

$this->Session->write('Auth.User', array_merge(AuthComponent::User(), $this->request->data'User']) );

à mettre dans l'action edit de ton contrôleur après la sauvegarde (si ton formulaire est bien en post évidemment.. )

Par contre, retire les données sensibles non modifiable dans le data pour éviter les problèmes de sécurité...

D'ailleurs une question de nature sécurité pour les spécialistes de cakePhp ^^

Le modèle User de cakephp est-il sécurisé de manière à ce que si l'on envoie ce que l'on veut en Post, (notamment un rôle ...) la mise à jour ne se fasse pas en base? (ni dans le composant Auth) par exemple, on soumet une requête Post "à la main"( avec les cookies etc.. qui vont bien)

Bonsoir.
@antho07 : Il te faut contrôler les champs que tu veux autoriser à la sauvegarde en base, CakePHP ne va pas deviner ce que tu as dans la tête.
Tu peux par exemple retirer des champs pour la sauvegarde dans un beforeSave dans ton modèle User dans le cas ou le rôle de l'utilisateur n'est pas égale à "admin" par exemple.

ou alors tout simplement dans le

$this->User->save($d,true,array('firstname','lastname','birthday','email','street','streetnb','pobox','cp','city','state','country_id','company'))){}

en spécifiant les champs à sauver

Lartak11, cela veut dire que si la personne a pas fait attention , on peut se passer admin en ajoutant un champ à la requête post ou en la fabriquant de toute pièce?

Ma question ne portait pas sur comment sécuriser etc.. mais juste sur le comportement par défaut.

Peut être que je me plante, mais d'après mes souvenirs, le modèle User est celui gérant par défaut les utilisateurs et donc l'authentification. On pourrait alors imaginer que pour ce modèle là (ou celui désigné par le composant auth) , des règles fortes soient mises par défaut. On doit explicitement préciser les champs de sauvegarde pour ce modèle, soit dans le modèle soit dans les contrôleurs par exemple..

Là , à ce que je comprend, si on précise rien et qu'on a en plus un champ indiquant si l'utilisateur est administrateur ou non en base, on se retrouve avec une faille béante de sécurité...

Question : sur 100 sites (amateurs.. j'ose espérer ne pas inclure les pros, m'enfin vu ce j'ai déjà pu voir sur certains... ) , combien ont fait ce contrôle lors de l'édition d'un profil ?

Bonjour.
J'ai dis qu'en contrôlant les champs autorisés à la sauvegarde, qu'il n'y a pas de risque qu'un utilisateur en change les données.
Le composant Auth limite les champs pour la connexion que tu lui as indiqué en déclarant ton composant Auth dans ton AppController, qui sont par défaut : "username" et "password", si tu veux utiliser d'autres champs pour connecter l'utilisateur, tu les lui défini dans l'appel du composant Auth dans ton AppController.
Pour les autres actions, il ne peut pas deviner tout seul ce que tu autorises à la sauvegarde, donc comme je l'ai dit, soit il faut les déclarer dans l'action correspondante lors de la sauvegarde, ou alors les définir par défaut dans le beforeSave du modèle User.
Si par exemple tu ne veux pas autoriser aux utilisateurs la modification du role sans avoir à le préciser dans chaque action de ton contrôleur, tu peux faire une condition dans ton beforeSave, du genre :

public function beforeSave($options = array()){
        if(!AuthComponent::user('role') == 'admin' && !empty($this->data'User']'role'])){
            unset($this->data'User']'role']);
        }
        return true;
}

Si tu n'utilises pas le composant Security, il peut très bien par exemple modifier le name "data[User][ville]" et l'id "UserVille" pour les passer en "data[User][role]" et "UserRole".
Ce qui ferait que ça modifierait le champ role par exemple.
C'est pour cela qu'il est conseillé de préciser les champs pour le save et ne pas y injecter en brut du genre :

$this->User->save($this->request->data);

D'ailleurs, Grafikart dans ses tutoriels le précise bien, à part pour les actions restreintes aux administrateurs, sinon il est fortement conseillé de préciser les champs à sauvegarder, même pour l'id de l'utilisateur, il vaut mieux faire un

$this->request->data'User']'id'] = $this->Session->read('Auth.User.id');

que de récupérer l'id de l'utilisateur retourné par le formulaire, pareil pour le champ user_id des tables jointes, ça évite par exemple qu'un utilisateur par un moyen détourné puisse modifier du contenu d'un autre utilisateur.
Donc si tu ne contrôles pas les champs pour la sauvegarde, tu risques des failles de sécurités pour ton site.
CakePHP a beau être un très bon Framework et proposer par défaut un certain niveau de sécurité, il est comme tous les autres, si tu ne fais pas toi même un minimum de "vérifications", la sécurité de ton site pourra présenter des failles.
Pour ta dernière question, pour ma part, la seule chose que je permet de modifier à un utilisateur de ma table users, c'est son mot de passe, ensuite il y a la table profiles qui ne contient que ses infos personnelles et son pseudo, donc s'il les modifies, ça n'influera pas sur la sécurité du site.
Pour les autres, je ne peux pas te dire comment ils procèdent, mais pour ma part je fais les vérifications nécessaires.
Je préfère passer quelques minutes de plus, que de risquer des failles de sécurité bêtement.

Lartack , je suis d'accord avec toi , pas la peine de me dire comment sécuriser^^.

Je disais simplement que puisque cakePhp connaît le modèle utilisé pour gérer l'authentification, ils pourraient faire une évolution afin de bloquer systématiquement à l'insertion toutes données relatives à ce modèle sauf celles précisées ici ou là peu importe. Ou même le faire pour tous les modèles.

Le composant Auth activé bloque tout si on précise rien.. son comportement par défaut est donc celui adapté, c'est à dire on coupe tout et ensuite on ouvre des portes.

Pourquoi ne pas mettre la même logique sur les modèles, c'était juste une discussion autour de ça, une pensée du soir quoi ^^ sous n'importe quel forme, tous les modèles, paramétrables, reliés cela à l'activation du composant auth etc...

Parce que hélas, oui c'est au développeur de prendre les mesures nécessaires etc... mais malheureusement des oublies sont possibles... avec une restriction par défaut.. ça évite ce genre de soucis. Je ne remets absolument pas en cause le framework etc... surtout que je le trouve très bon , je pense juste à une petite évolution possible , après tout pourquoi pas , ça vit un framework , au grès du temps, remarques, bugs, failles, évolutions techniques, idées..

cordialement