Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Id unique(Entier) à partir d'une chaine
Bonjour,
dans ma base de données je souhaite logguer l'activité des utilisateurs de mon application. Ces derniers sont identifiés par l'annuaire LDAP de la boite donc l'id que je possède est une chaine. Le problème c'est que le champ id_personnel est en entier. Il me faudrait donc une méthode pour obtenir un entier unique qui serait une conversion du login (ex : thomas.dubois) en entier.
Pensez vous que ce soit possible ? Quid de l'unicité d'un tel id ?
Je doutes que tu arrives a convertir une chaine en un Id vraiment unique sur un entier...Pensez vous que ce soit possible ? Quid de l'unicité d'un tel id ?
Pourquoi pas ajouter a ta table d'employes un champ "pogin_personnel", qui soit le login LDP du gars, avec une contrainte d'unicite ?
un algo simple c est de prendre chaque caractere, de prendre son code ascii corespondant, de concatener le tout, et de le convertir en entier
apres je sais pas trop pourquoi tu veux faire ca mais bon...
En fait je pensais à faire une conversion caractère par caractère en entier.Envoyé par pvialatte
En fait l'authentification se fait par le ldap, le mot de passe n'est pas stocké dans la base de données. Il y a effectivement une table profil qui stocke les id, login et les droits associés, mais en cas de changement de profil, l'id change.
un hash, c'est fait pour ce que tu souhaites faire.
mais n'utilise pas MD5, prend SHA1 ou postérieur
bien sûr ca te fait changer le type du champ en base mais t'as pas trop le choix. ou sinon, si tu peux VRAIMENT PAS changer le type du champs, tu le laisses de coté, et tu rajoutes une autre colonne pour mettre ton hash
moi c'est Louis-Guillaume, ni Louis, ni Guillaume mais Louis-Guillaume et je n'aide pas ceux qui écorchent mon nom
Oui c'est ce que j'étais en train d'écrire
J'oubliais de préciser qu'en fait les tables dont on veut surveiller les modifications ont été prévues pour stocker un id_personnel entier. Le problème c'est qu'elles sont nombreuses, et vu que nous avons déja commencé à coder dans ce sens, il serait compliqué de tout refaire.apres je sais pas trop pourquoi tu veux faire ca mais bon...
en gros, tu préfères partir dans l'idée de faire directement du bricolage alors qu'il vaut mieux prendre le temps de corriger maintenant que plus tard. une erreur de design, ca arrive souvent mais quand ca touche autant de choses, c'est le plus rapidement possible qu'on cherche à le corrigervu que nous avons déja commencé à coder dans ce sens, il serait compliqué de tout refaire.
moi c'est Louis-Guillaume, ni Louis, ni Guillaume mais Louis-Guillaume et je n'aide pas ceux qui écorchent mon nom
+1 : j'appuie cette suggestion.
A nouveau, suivez la recommandation de Louis-Guillaume ; faites un effort, vous vous en féliciterez plus tard ;
Mais si vous ne pouvez vraiment pas vous permettre d'impacter autant votre MPD, dans ce cas, introduisez seulement une table d'association contenant les "hash" suggérés ci dessus, et faisant office de table de séquence (générative) des "id_personnel" dans vos autres tables ; mais ce n'est qu'un pis aller car il y aura de toute façon un impact sur votre code applicatif, au moment de sélectionner un "personnel" via cette indirection ; un impact que n'auriez pas en suivant l'idée de Louis-Guillaume.
'HTH
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
++ aussi
Je n'ai pas les chiffres sous la main, mais plus un changement de design intervient tard, plus il coute cher...
en fonction de tes utilisateurs, tu risques d'avoir des depassements de capacites...prendre chaque caractere, de prendre son code ascii correspondant, de concatener le tout, et de le convertir en entier
J'ai un collegue dont le login LDAP tiens sur 20 caracteres, ca fait donc, avec ce systeme, une valeur numerique qui peut aller jusqu'a 2626262626262626262626262626262626262626...fais attention aux types de données, alors
En fait l'authentification se fait par le ldap, le mot de passe n'est pas stocké dans la base de données. Il y a effectivement une table profil qui stocke les id, login et les droits associés, mais en cas de changement de profil, l'id change.
et pourquoi tu n'utilises pas l'id qui est dans cette table ?
De toute facon, pour ton probleme de base (logguer l'activité des utilisateurs de mon application), si le login LDAP de ton utilisateur change, ton appli le considere comme un nouvel utilisateur....
Le hash ne répond pas au besoin. Même si c'est plus ou moins rare suivant la taille du hash, deux chaines différentes peuvent donner le même hash par définition. Donc le hash ne garantit en rien un id unique.
A lire : Les règles du forum
oui c'est ce qui a été démontré avec MD5 encore récemment mais pour faire une collision sur du SHA-1 ou meme mieux du SHA-256 il faut y aller.
le principe même d'un hash c'est de se prémunir de cela et s'ils ont prouvé avec un gros brute force et en cherchant bien on pourrait PARFOIS forcer une collision sur du MD5 (qui a je sais pas combien d'année), sur du SHA-256, on a jamais pu prouvé de collision sur celui-ci.(sur SHA-1, c'est pas vraiment une colission mais une attaque en modifiant le nombre d'opération qui a été trouvé)
c'est donc pour le moment très fiable.
comment represénterais-tu un utilisateur de façon unique sinon, sachant que les données peuvent changer? (je te vois venir avec un XOR)
moi c'est Louis-Guillaume, ni Louis, ni Guillaume mais Louis-Guillaume et je n'aide pas ceux qui écorchent mon nom
Non. Le principe d'un hash c'est de fournir une signature d'une valeur. Typiquement, stocker les hash de password et comparer les hashs est considéré comme plus sûr que de stocker des mots de passe et de les comparer littéralement.
Réduire le nombre des collisions améliore le taux de confiance, mais ne garantit toujours pas l'unicité.
Si tu as besoin d'un id unique, coder cela avec un hash, c'est accepter une probabilité de bug un jour ou l'autre (très faible dans ce cas je te l'accorde, mais chaque compromis réduit la fiabilité globale du système).
La solution que je verrais est de renseigner une table de correspondance quelque part dans le système, avec assignation d'un nouvel id si l'utilisateur n'est pas dans cette table de correspondance, et récupération de l'id préalablement assigné s'il est trouvé.
Bien entendu l'idéal serait d'utiliser l'id préexistant dans LDAP, qui éviterait d'avoir à reprendre les données de cette table de correspondance en cas de changement de nom d'utilisateur.
A lire : Les règles du forum
+1 ; tout à fait, c'est ce que je n'ai pas traité quand je parlais de ma "table d'association" dans ma première réponse ci dessus ; bien sûr, en général (j'espère), tous ceux d'entre nous comme Louis-Guillaume qui connaissent le principe des fonctions de hash savent également que ces fonctions sont, par construction, sujettes à collision... ce qui nécessite, lors de l'insert du hash dans une telle table d'association avec les "simples id entier", que le hash du texte n'a pas déjà été inséré pour un autre id, et agir en conséquence...
+1
Maintenant, franchement, j'appuie a nouveau Greybird contre la solution à base de table de hash, même si l'éventualité des collisions est gérée correctement pour parer à celles-ci ; les hash sont d'abord conçu pour des cas d'utilisation ayant besoin d'empreintes (sur passwords, versioning, etc), et pas pour faire des foreign keys... qui est alors un usage où on "s'amuse à tordre le cou" au concept, amha.
C'est un peu (je sais, c'est assez eloigné, dans les apparences) comme si on utilisait des ilots XML pour transporter du binaire "pur" sur le cable (sans aucun contenu "texte" communément identifié comme tel).. a la rigueur, si c'est sur HTTP, pourquoi pas (genre : <data>...encodé en base64 ou autre..</data>), mais quand le transport peut "descendre d'un cran" pour le besoin, au niveau "plus naturel" des sockets TCP/UDP, on ne va plus s'amuser à ça : les classes streams et readers (travaillant sur des byte[]) sont là pour ça..
oh bon.. je digresse... my bad (c'est juste que je l'ai vu faire, "l'amusement", ahem!
)
'HTH
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Ok c'est noté. Je ferai le changement.en gros, tu préfères partir dans l'idée de faire directement du bricolage alors qu'il vaut mieux prendre le temps de corriger maintenant que plus tard. une erreur de design, ca arrive souvent mais quand ca touche autant de choses, c'est le plus rapidement possible qu'on cherche à le corriger
Je n'y avais pas du tout pensé j'avoue effectivement le cas peut se produire.en fonction de tes utilisateurs, tu risques d'avoir des depassements de capacites...
J'ai un collegue dont le login LDAP tiens sur 20 caracteres, ca fait donc, avec ce systeme, une valeur numerique qui peut aller jusqu'a 2626262626262626262626262626262626262626...fais attention aux types de données, alors
Ce n'est pas le login qui change souvent, mais les droits associés a un utilisateur, et l'id associé dans la table profil. Mais sur le principe tu as raison.
Oui elle est faible, car de toute facon il n'y aura qu'une vingtaine d'utilisateurs, mais on va s'en passer du hash.
Effectivement bonne idée.
Justement je me suis posé la question, existe t'il un id numérique unique par utilisateur dans LDAP ?
Hum ça dépasse mes connaissances. Au pire j'imagine qu'on doit pouvoir rajouter une info de ce genre dans le ldap.
A lire : Les règles du forum
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Vous voulez contribuer à la rubrique .NET ? Contactez-moi par MP.
Partager