Hey ,

J'aimerais programmer un paquetage de gestion d'authentification. Je regarde donc à droite et à gauche ce qui se fait. Je regarde notamment Zend_Auth. Qu'en pensez-vous ? Comment fait Symfony ? Est-ce qu'il existe un système qui facilite les choses, qui fait ça bien ? Si non, alors qu'est-ce qui coince ?

Gérer une session, c'est facile et on peut faire ça facilement. Mais les données qui valideront l'authentification peuvent être sous plusieurs formes (XML, SQL etc.). Existe-il des cas complexes d'authentification ? Quels sont les différentes méthodes de persistances d'authentification (HTTP, Cookie, Session, mais encore ?) ?

J'aimerais un peu savoir ce que chacun utilise. Si possible dans un domaine professionnel, c'est plus intéressant .

Merci .

Gestion des sessions en PHP, utilisation de MYSQL avec des champ type BLOB géré par du AES_ENCRYPT / AES_DECRYPT.

Utilisation pour des extranet en milieu pro.

A partir de la niveau sécurité je vois pas comment aller plus loin.

Personnellement, je crois que chaque framework à sa méthode basée sur le fonctionnement des sessions php.
Cookie, identifiant de session, et tableau sérialisé dans un fichier
Après, c'est la méthode d'accès et de traitement qui différe.
Dans tous les cas on a une base de données (au sens large du terme, et donc pas seulement un SGBD).
On peut avoir un système de type (XML-)?RPC qui serait utile dans le cas d'une sorte de centrale de login à la manière OpenId ou une base de données unique accessible sur le serveur soit sur un fichier texte, formaté comme l'on souhaite, un tableau sérialisé comme les sessions stocké dans un fichier, un fichier XML, un fichier YAML, ou une base de donnée standard accessible par Sql, Linq ou autres.
Après, il faudrait faire des bench, valider les hypothéses de travail (comment faire si la centrale de login tombe en rade sur une application critique ?)
Après avoir récuperé les données de login et validé la connexion de l'utilisateur, on doit gérer la persistance de la dite session. Mais comment ?
On fait soit-même son système de sessions ? On utilise le mécanisme integré ?
Que de questions
Si c'est pour Hoa, essaie de faire une sorte de classe générique avec des méthodes génériques et des adapter pour pouvoir élaborer soit même par la suite ses méthodes d'authentification de l'utilisateur
Une seule méthode pour gérer les sessions, mais faire en sorte que ces données puissent être stockées dans une table de sessions par une méthode de callback incluse dans la classe générique et appellée a l'enregistrement des données.
Enfin bon, après on part dans une certaine méthode qui a cette heure-ci commence déjà à brouiller mon encéphale fort endommagé ce jour

Oui c'est pour Hoa et oui je vais utiliser un jeu d'adaptateur, et c'est pour ça que je souhaite avoir le plus d'opinion possible afin de faire le maximum d'adaptateur .

J'essaierais, si je suis pas trop crevé en rentrant du boulot ce soir, de tenter de faire un schéma uml ou autre pour expliquer le fond de ma pensée

Ne te sens pas obligé. J'ai déjà tout ça en tête. Je veux juste connaître les méthodes de chacun et de chacune .

moi je part sur du sql/php pour l'authentification et je récupére une fois connecter une global $_USER qui est en faite un tableau de droit pour l'user. par la suite je gère aisément ceci dans mes divers script en m'appuyant sur cette global... Je suis en train de regarder du coter de zend_auth donc pour le moment mon opinion reste restreint tout de même

@HyWan: qu'entend tu par jeu d'adaptateur ?

Un adaptateur c'est quand tu introduis une couche d'abstraction entre deux couches. En fait, tu passes tout à travers une interface, donc on est en plein polymorphisme. Et quand tu utilises ta classe frontale, tu dis quelle classe tu veux derrière (DB, OpenID, HTTP etc.). Pour pouvoir communiquer vers ces classes, on utilise un adaptateur. En général, on utilise une interface ou une classe abstraite — pour le polymorphisme — couplée avec un design pattern strategy — pour pouvoir changer d'objet à volonté —. Ça te cause ou pas du tout ?

c'est encore un peu top pour ma POO mais je le conçoit très bien
merci

Bah, moi personellement, dès qu'il veut se connecter je teste ses identifiants et j'entre son id et son pseudo en session, à chaque début de page je reteste son identité (SELECT id,pseudo WHERE id=$_SESSION['id'] (en gros)) puis je vérifie si son pseudo colle bien avec son id, puis je définis 3 variable :
$utilisateur->id
$utilisateur->pseudo
$utilisateur->connecte // si 1 l'utilisateur est connecté si non il n'est pas logger
Je penses qu'il y a une faille me je ne vois pas comment la résoudre...

Si tu re-récupères sur chaque page le login, ça sert à rien d'utiliser une session...
J'attire l'attention sur un point particulier :

Par défaut, lorsque l'on fait session_start() en PHP (en imaginant un système de d'authentification basé sur les sessions), les directives de cache sont modifiées (Cache-Control) pour ne pas mettre les pages en cache navigateur. Je ne suis pas^vraiment sûr que ce soit au système d'identification de gérer ça, mais c'est un point à connaître (session_cache_control() permet de maîtriser ceci).

Sinon, perso, SQL/PHP basique avec variables de sessions... Pour savoir si la session est démarrée, je regarde $_SESSION['start'] qui contient le timestamp de début GMT (strtotime('now GMT') si mes souvenirs sont bons). J'y stocke tout ce qui concerne l'utilisateur : id, login (PAS le mot de passe), mais également d'autres informations très pertinentes dans une session : les personnalisations de l'interface (messages par page, jeu de couleurs, etc.), qui allège beaucoup la BdD.

En gros, j'ai parlé de 2 trucs : gestion du cache (persistence) et de données diverses (pas que id/login).