Auth, plugin ou self-code?

[Viciousity]

Bonjour tout le monde,

Je poste ici pour récolter quelques avis. En effet, je me tâte depuis quelque jours pour savoir si je crée un système d'identification maison ou pas...

J'ai essayé différentes solutions auparavant comme Authlogic, devise, etc... (pour rails)
Mais je trouve qu'ils ne sont totalement pas personnalisable ou du moins, pas du tout facile a customiser.
Du coup je me demande si au point de vue des performances, créer le sien n'est pas mieux.

Merci d'avance, Viciousity.

[srm]

Il faut savoir, le problème c'est la customisation ou les performances ?

[Viciousity]

Ben je cherche a concevoir de manière la plus légère possible mon application afin de maximiser les performances de celle-ci.

D'un coté, codé soi-même permet de maitriser ce facteur mais il augment aussi terriblement les lignes de codes ...

[Sephi-Chan]

Je ne pense pas que des solutions comme Devise ou Authlogic altère les performances.
Que cherches-tu à customiser ?


Sephi-Chan

[Viciousity]

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

---

Maintenant une question aux utilisateurs de rails.
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.

[Sephi-Chan]

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 ?

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

[Viciousity]

Mouais pour les jetons c'est pas faux que utiliser une solution toute faites est certainement interessante ^^ (a coder c'est plutôt chiant bien que simple)...

Maintenant je pensais plus a une mise en cache sécurisée que l'on mettrai a jour avec un 'after_update' dans le modele mais le soucis vient des associations a gérer.
Personnellement j'ai encore du temps pour y réfléchir vu que je ne compte pas accueillir 10000 joueurs lors de la bêta (meme si c'est un rêve ><)

Et quand tu dis que 'SELECT * FROM users WHERE persistence_token = '...';' est simple, ok mais quand tu as 10000 joueurs de connectés sa fait vite beaucoup :S

[Sephi-Chan]

Je te souhaite d'avoir 10000 connectés permanents. Cela dit, quand ce sera le cas, tu auras probablement une infrastructure plus solide, tu auras une base de données qui utilise la réplication, ce qui rendra les lectures très rapide, etc.

Attend d'avoir besoin de faire des choses moches pour penser à faire des choses moches. L'extensibilité (scalability) a un prix : elle oblige parfois à faire des choix peu orthodoxes.

Anticiper c'est bien mais il faut rester réaliste et pragmatique.


Sephi-Chan

[Viciousity]

Mouaip c'est pas faux mais je trouvais la question interessante toute de même (trop de curiosité tue la curiosité ;P)

[Sephi-Chan]

Ah mais je ne remets pas en cause l'intérêt de la question. Bien sûr que c'est intéressant ! Ça permet de discuter du sujet de fond "système maison VS système éprouvé par la communauté" !

Il faut relativiser les avantages (sur le plan des performances) du code "maison". C'est plus léger au début, quand le système ne sait rien faire, on se sent fier de son minimalisme : ensuite — puisqu'on est dans la vrai vie — de nouveaux besoins émergent. On a besoin d'une fonctionnalité, qui consiste à générer un token à usage unique (pour les mails d'activation ou les procédures d'oubli de mot de passe, notamment), et à en régénérer une fois que le précédent est utilisé. Dans Authlogic, il suffit d'avoir une colonne perishable_token pour que cette fonctionnalité soit prise en charge. Bref, le code s'enrichit, se complexifie. Le système maison perd de son minimalisme, l'écart de performance tend à diminuer.

Ensuite, l'évolution du code. Authlogic est beaucoup utilisé. Son code est souvent mis à jour : pour la sécurité, pour les performances ou que sais-je encore. Est-ce parce qu'il est truffé de bug ou lent et lourd ? Ou est-ce parce que plusieurs personnes ont cherché à l'améliorer ? Le système maison sera-t-il aussi bien maintenu ?

Enfin, un autre point en faveur des outils éprouvés : les tests. Dans la communauté Ruby, il y a une véritable culture du test : n'espère pas soumettre une fonctionnalité à l'équipe d'Authlogic, de Devise ou même de Rails si tu ne fournis pas les tests associés. Authlogic est très testé. Le système maison aura-t-il sa batterie de tests (et seront-il maintenus à jour) ?

Attention donc de ne pas oublier trop d'éléments lors de la pesée des pours et des contres !


Sephi-Chan