03-01-2011, 08:24 PM
(Modification du message : 03-01-2011, 08:25 PM par Sephi-Chan.)
(03-01-2011, 07:46 PM)Viciousity a écrit : Ben des champs a rajouter, des validations sur ceux-ci, changer les validations de base, les méthodes de recherche de login... bref pas mal de truc ...
Mais bon je viens de créer mon système d'auth et je dois dire que je suis pas mal décu du resultat
Sur 1000 pages chargée mon current_user bouffe moins de ressource que celui de Authlogic ou Devise donc nikel
Tout ce que tu cites est faisable très simplement avec Authlogic (et très certainement avec Devise). Jette un coup d'œil à la documentation avec de mettre un outil de côté.
Je ne suis pas sûr que tu y gagnes. Authlogic, c'est aussi une prise en charge très simple des grains de sel, du chiffrement, des jetons d'accès (perishable, single access et persistence). Je ne me retaperais ça pour rien au monde !
Est-il vraiment pertinent de rogner là-dessus ?
(03-01-2011, 07:46 PM)Viciousity a écrit : N'avez vous pas une solution pour stocker de manière sécurisée une constante dynamique (current_user ici) de manière a éviter des transactions serveur<=>BDD a chaque chargement. Une espece de mise en cache mais au niveau d'une variable de manière a la stocker de manière permanente tant qu'on ne la détruit pas ou qu'on ne la modifie pas.
Là aussi, avant de proposer une solution, je pose la question : est-ce pertinent ? Que veux-tu économiser ? Une requête type SELECT * FROM users WHERE persistence_token = '...'; ? C'est pourtant une requête triviale et donc très rapide pour un SGBDR (qui plus est avec un index sur la colonne persistence_token).
Si vraiment tu veux faire ça, tu peux toujours utiliser un système de stockage par clé/valeur comme Redis ou Memcache, avec comme clé le token de persistance et comme valeur l'objet User. Ça ne me semble pas pertinent puisque ça implique de synchroniser l'objet en mémoire et celui en base de données : de la complexité inutile.
Sephi-Chan