J'ai utilisé Django avant (version 1.2) et généralement je l'aime ... Il est particulièrement bon d'obtenir un nouveau projet de manière rapide et courante. Mais dans ce cas, je réécrit et le système existant et je l'ai déplacé à Python / Django. Donc, j'ai déjà une base de données MySQL qui possède une table de "utilisateurs" ... Cette table stocke le mot de passe de l'utilisateur avec la fonction MySQL SHA1 (pas de sel, etc.).
Dans le cadre de la migration, je vais résoudre certains des défauts de modélisation de données et du port vers PostgreSQL.
J'aimerais vraiment utiliser django.contrib.auth, mais je ne suis pas clair ce que je dois faire. J'ai lu la documentation et sachez que je peux séparer les informations de l'utilisateur requises et les informations «supplémentaires» que j'ai et que je l'ai mise en userProfile.
Mais, comment gérer les mots de passe stockés dans la DB mysql?
Quelqu'un a-t-il déjà géré cela? Quelle approche avez-vous pris?
3 Réponses :
Vous pouvez probablement le mettre directement dans le champ Sinon, vous pouvez simplement définir un mot de passe inutilisable (la chose canonique à faire est de définir le champ sur user_password - voir Les DJANGO DOCS . Puisque vous n'avez pas de sel, essayez d'utiliser le format SHA1 $$ mot de passe_hash . Je n'ai pas étudié pour voir que cela fonctionnera avec un sel vide, mais c'est probablement la seule façon dont vous pourrez peut-être migrer sans piratage django.contrib.auth ou écrire votre propre backend d'authentification.
! ) pour les utilisateurs et signalez-les sur le système Mot de passe oublié.
Juste pour clarifier, Dougai conseille de placer les hachage de mot de passe dans Django, préfixé avec les 6 caractères littéraux " sha1 $$ ", si mon mot de passe était "Mot de passe", dans MySQL, le champ de mot de passe hachée serait < Code> 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 Vous devez donc insérer SHA1 $$ 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 dans la base de données.
Je suis enfin rentré dans ce projet et j'ai eu la chance de tester cela. J'ai dit que cela indique que cela faisait pas travail.
@Davids, c'est probablement parce que le Code correspondant Est-ce que affirme sel . Je pense (bien que cela soit non testé), la bonne approche consiste à faire un hasard personnalisé qui ne nécessite pas de sel. C'est: Sous-classe django.contrib.auth.hashers.sha1passwordshasher , définir algorithme = "sha1unsalt" , copie encode () sans le affirmer , remplacer sel () pour renvoyer '' ', ajoutez cette classe à paramètres.password_hashers et modifiez les mots de passe dans Le dB pour commencer par Sha1unsalt $$ . Je pense que cela devrait fonctionner ....
@Dougal. Merci pour la réponse. Cela ressemble à une bonne approche. Une question. Password_hasher est-il disponible en 1.3? Il semble que ce ne soit que du document dans la branche actuelle "Dev" et semble être quelque chose qui se fait travailler pour 1,4. Est-ce exact?
Ouais, cela semble être nouveau pour 1,4; Désolé, je viens de regarder dans la branche principale. Le code correspondant pour 1.3 est ici < / a> - Je ne vois pas en un coup d'œil pourquoi un sel vierge ne fonctionne pas avec ce code, ce qui me fait craindre que ce soit quelque chose d'autre causer le problème? Vous pourriez essayer avec le 1.4 Alpha, cependant, et si votre projet ne sera pas fait avant l'avanceur, vous pouvez simplement vous en tenir à cela. (Ou aller vivre avec n'importe quelle bêta est à jour lorsque vous avez terminé, ce qui n'est pas recommandé mais irait probablement d'accord.)
Je ne sais pas depuis quand il est là, mais dans 1,5, il y a déjà non analysha1passwordhasher dans django.contrib.auth.haghers
Voici ce que j'ai fait pour faire fonctionner les choses. J'ai créé un backend d'authentification personnalisé. Remarque: J'utilise l'adresse e-mail comme nom d'utilisateur.
Voici mon code: P>
AUTHENTICATION_BACKENDS = (
'my_website.my_app.my_file.MyUserAuthBackend',
)
C'est une belle solution mais quelques notes. Vous voudrez peut-être utiliser une comparaison de chaîne de temps constante: code.djangoproject.com/browser/django/tags/relases/1.3.1/... . Vous pouvez également vouloir prendre le temps de migrer les mots de passe Legacy sur le format Django à l'aide de Set_Password, car vous avez le mot de passe à ce stade.
@Mark - J'ai regardé la fonction constante_time_compare au moment où je développais ma solution. Je suppose que je n'ai vraiment pas complètement compris le point de celui-ci. En outre, un excellent point sur la sauvegarde du mot de passe. Je vais l'ajouter à la solution ci-dessus. Merci!
La fonction Constat_Time_Compare est là pour prévenir les attaques de synchronisation. Le fil DJANGO-DEV sur son but est une bonne lecture: Groupes.google .Com / Groupe / Django-développeurs / Browse_thread / Thre Ad / ...
Merci Mark. J'ai lu les informations et j'ai décidé de mettre à jour la réponse / la solution avec elle.
Les versions récentes de Django fournissent un hasher pour des mots de passe de hérité non salés. Il suffit d'ajouter ceci à votre fichier de paramètres: