2009-07-15 16 views
0

J'ai du mal à comprendre comment je devrais remplacer les équivalents et obtenir un code haché pour une classe que j'écris en utilisant NHibernate.Comment remplacer les équivalents pour une classe spécifique de NHibernate

Le scénario de gestion de base est que les utilisateurs ne peuvent pas réutiliser le même mot de passe dans une limite de 90 jours.

Donc j'ai un "utilisateur" qui a beaucoup de "mots de passe historiques" ... la classe d'utilisateur était facile car j'utilise juste le login dans les égaux. Voici ma classe HistoricalPassword. Je dirais d'un point de vue commercial que la combinaison de l'utilisateur et du ChangeDate me donnerait l'égalité. Cependant ... il ne semble pas correct de référencer l'utilisateur dans la méthode equals (puisque pour une chose qui provoquerait une charge paresseuse) ... et aussi de ce que j'ai lu en utilisant le PK de HistoricalPasswordId est un non-non ainsi que.

Quelqu'un peut-il fournir des conseils sur la façon dont ils remplaceraient des égaux pour cela?

EDIT ::: Je pense que je pourrais avoir été un peu trompeur sur la façon dont j'ai posé la question. Je ne suis pas confus sur la façon d'appliquer la règle métier de s'assurer que les mots de passe ne sont pas réutilisés ... ni sur la façon dont je sais si deux mots de passe sont égaux ou sont sécurisés. Ce que je veux vraiment savoir, c'est qu'au niveau de l'entité, spécifiquement lié à NHibernate, comment devrais-je remplacer Equals pour cet objet afin que NHibenate ne finisse pas avec des dupes dans la session et/ou le cache. Selon le document NHibernate (https://www.hibernate.org/hib_docs/nhibernate/html/persistent-classes.html), je devrais remplacer les égaux en utilisant l'égalité des clés commerciales. Dans ce cas, je ne suis pas sûr si l'utilisation de l'objet référencé de l'utilisateur dans la comparaison est une bonne idée.

Répondre

2

Je ne remplacerais pas Equals pour cela - vous n'allez pas affirmer que ces enregistrements sont égaux, simplement qu'ils font référence au même mot de passe, n'est-ce pas?

Vous avez certainement besoin d'une requête HQL ou d'un critère qui vous donne les mots de passe historiques définis au cours des 90 derniers jours?

EDIT: Vous pouvez également vérifier comment vous stockez votre mot de passe. Les mots de passe en clair dans la base de données ne sont pas une bonne idée. Il se peut que vous ayez un type d'utilisateur NHibernate qui déchiffre un mot de passe crypté dans la propriété de chaîne que nous pouvons voir, bien sûr ...

+0

Merci pour votre réponse rapide ... et mon inquiétude sur ma sécurité :) Par souci de simplification, supposons que mes mots de passe sont sécurisés. Mais revenons au problème ... J'ai l'impression qu'il y a cette partie de ping-pong qui va et vient sur les gens qui disent que vous devez ignorer equals et gethashcode sinon vous êtes condamné à utiliser NHibernate car vous finirez avec des dups dans votre session ... et puis il y a autant de personnes qui disent ne pas déranger ou simplement utiliser le PK dans le contrôle de l'égalité ... !!! yikes !!! – Todd

+0

L'égalité de l'entité est identique à l'égalité de la clé primaire, donc remplacez Equals en conséquence. Mais ce dont vous parlez, ce n'est pas l'égalité réelle, mais une autre forme d'équivalence. –

0

Je considérerais le paramètre HistoricalPassword comme étant un objet de valeur, pas une entité. Donc, cela signifie que son 'ID' serait déterminé par la valeur de toutes ses propriétés.

0

Deux façons d'y parvenir.

Si vous voulez le faire en utilisant l'égalité, l'utilisateur sera impliqué, en particulier le PK de l'utilisateur. L'égalité serait l'utilisateur PK + le mot de passe. La date n'aurait pas d'importance. Cela complique probablement les choses, cependant, et je ne ferais probablement pas de cette façon.

Une autre façon est d'utiliser seulement le mot de passe pour l'égalité, puisque c'est ce que vous comparez à la fin. L'utilisateur ne sera utilisé que dans la requête, idem la date de modification. Effectuez une requête HQL pour obtenir les mots de passe historiques où user = {user} et modifier la date < (aujourd'hui - 90). Cela retournera tous les mots de passe des 90 derniers jours pour {user}. Une fois ce problème résolu, tout ce que vous devez faire est de comparer les mots de passe pour voir s'il y a correspondance, puisque vous avez réduit votre jeu de résultats aux seuls mots de passe des 90 derniers jours pour {user}.Enfin, comme mentionné ci-dessus, faites simplement une requête HQL pour {user} où la date a changé < 90 et password = {nouveau mot de passe}. Si vous obtenez des résultats, vous savez que le mot de passe a été utilisé dans les 90 derniers jours. Enfin, comme mentionné plus haut, ces comparaisons supposent toutes que vous jouez avec des mots de passe en clair ou que vous cryptez le nouveau mot de passe pour le comparer aux anciens mots de passe. D'une manière éther, quelque chose doit être fait pour rendre compte de la sécurité des mots de passe.