Créer numéro de référence sans bdd

[mtth]

Bonjour,

Je dois créer un numéro de référence unique mais je n'utilise pas de base de données ... J'utilise Google form que j'ai un petit peu traficoté a ma manière ...

Quelqu'un a une idée?

Merci d'avance

Mtth

 

[FortTrafic]

est-ce que le formulaire demande une adresse email unique? Si c'est le cas tu peux utiliser ça.

 

[mtth]

Bonjour,
J'utilise l'adresse mail comme référence? Oui j'y ai pensé mais un numéro (ex: 047) serait quand même beaucoup plus simple a retenir et a manipuler... Le but est de l'utiliser en tant que communication lors du virement bancaire ...

Qq a un idée?

Un grand merci,

Mtth

 

[MikeR]

Tu peux utiliser du js sur ta page? Dans ce cas tu peux faire une requète en ajax vers ton site vers un script php qui retourne un compteur incrémenté à chaque appel (tu le stockes dans un simple fichier).
Sinon, tu peux utiliser un timestamp légèrement bidouillé pour le rendre unique.

 

[mtth]

Oui je pense que , si j'ai le temps, je ferai le truc avec l'Ajax. Surtout que j'utilise deja du Ajax pour envoyer un mail de confirmation (car Google Forms ne le fait pas (encore)). Donc je vais alors créer un p'tit script pr cela

Par contre j'ai pas vraiment compris le truc avec le timestamp ...

Merci beaucoup!

Mtth

 

[MikeR]

Je pensais au timestamp unix, qui est en secondes, donc avec un risque d'avoir deux utilisateurs qui effectuent la transaction la même seconde. L'idée étant de concaténer un nombre au hasard de façon à être sur d'éviter des collisions.

Mais à la place du timestamp unix, tu peux utiliser la fonction Date().getTime() qui donne un timestamp à la milliseconde, avec un risque de collision quasiment nul.
voir http://stackoverflow.com/questions/221294/how-do-you-get-a-timestamp-i ... javascript

Correction : la fonctions s'exécutant sur chaque browser, on n'est pas sur de leur synchro, donc la soluce ajax est meilleure.

 

[UsagiYojimbo]

Mais dans Google Forms, il y a peut-être moyen de nativement disposer d'un champ auto-incrémental non ?

Edit : peut-être pas nativement, mais il y a une solution : http://webapps.stackexchange.com/questions/15449/can-i-add-an-autoincr ... oogle-form

 

[mtth]

Oui mais c'est une bibliothèque js? Car leurs fonctions je ne les ai jamais vues (mais je suis débutant! ) je vais voir sur Google forms mais sinon je vais utiliser le fichier avec Ajax ...

Merci
Mtth

 

[ortolojf]

Bonjour Monsieur

Si vous disposez d'une variable unique fournie par le client, ( email par exemple ), vous pouvez prendre le hash code sha256sum de cette adresse email :

$identifiant_unique = hash('sha256', $email);

Le code produit est sur 256 caractère alphanumériques.

Identifiant unique sans aucun doute.

Voir la page du PHP Manual pour la fonction hash().

Respectueusement.

Jean François Ortolo

 

[mtth]

Bonjour Ortolojf

Merci pour votre idée, mais une chaine de 256 caractère de long n'est pas tres utile a manipuler... Je cherche une chaine de genre maximum 5 caractères de long. Ca servirait a savoir qui a déjà payé et qui pas ...

Un grand merci

Mtth

 

[ortolojf]

Bonjour Ortolojf

Merci pour votre idée, mais une chaine de 256 caractère de long n'est pas tres utile a manipuler... Je cherche une chaine de genre maximum 5 caractères de long. Ca servirait a savoir qui a déjà payé et qui pas ...

Un grand merci

Mtth

Bonjour Monsieur

La fonction hash() ( dixit le PHP Manual ), acepte plusieurs formes de premier paramètre.

Suivant ce premier paramètre, le nombre de caractère ( identificateur ) est variable, et peut aller jusqu'à 8 caractères alphanumériques au minimum, par exemple pour les premiers paramètres : 'adler32', 'crc32b', et 'crc32'.

Le premier paramètre, est l'algorithme de hashage.

En ce qui me concerne, j'utilise sha256 ( 256 caractères ) pour remplacer des adresses ip, pour ne pas être en conflit avec la Directive Européenne ou la CNIL, ceci pour la même utilisation ( identificateur unique ).

Quant à savoir si avec 8 caractères alphanumérique l'identificateur est effectivement unique, c'est un autre problème...

Bien amicalement.

Jean François Ortolo

 

[zeb]

Faire dépendre un identifiant unique d'une donnée utilisateur c'est une très très mauvaise idée ... Le mail c'est surement ce qu'il y a de pire.

 

[ortolojf]

Faire dépendre un identifiant unique d'une donnée utilisateur c'est une très très mauvaise idée ... Le mail c'est surement ce qu'il y a de pire.

Bonjour zeb

Problème.

Un identificateur de 5 chiffres, ne peut pas, par définition, être unique.

Quant à l'algorithme sha256sum, il me sert pour vérifier la justesse de gravure de mes DVD.

Sinon, en ce qui concerne le problème posé, c'est un problème ultra-classique en conception Informatique, et tout dépend des données exploitables, et/ou des moyens de calcul.

Sinon, n'importe quelle donnée unique au départ, peut faire l'affaire.

Mais... Un id de 5 chiffres, boafff...

Faut voir que même avec de la manipulation de fichiers, ( pas de bdd ), on peut très facilement assurer le caractère unique d'un identificateur allant largement au delà de 1024 caractères.

Ou bien voir sur le net...

Respectueusement.

Jean François Ortolo

 

[mtth]

Faire dépendre un identifiant unique d'une donnée utilisateur c'est une très très mauvaise idée ... Le mail c'est surement ce qu'il y a de pire.

bonjour a tous,

Zeb je nai pas vraiment compris pourquoi cest mauvais ... Et pour le moment je Me debrouille avec un fichier que jouvre avec php et que je mets a jour.

Un grand merci

Mtth

 

[zeb]

Faire dépendre un identifiant unique d'une donnée utilisateur c'est une très très mauvaise idée ... Le mail c'est surement ce qu'il y a de pire.

Un identificateur de 5 chiffres, ne peut pas, par définition, être unique. (...)

J'ai Jamais parlé d'id a 5 caractères personnellement. Je n'ai parlé que de le construire avec un mail car c'est une mauvaise idée. :wink:

 

[zeb]

Zeb je nai pas vraiment compris pourquoi c'est mauvais ...

C'est mauvais car :
* ça viens de l'utilisateur (donc c'est jamais "safe")
* le résultat est prédictible par l'utilisateur (si il comprend le comment) donc de là possible exploitation.
* l'utilisateur peut utiliser la donnée d'un autre (même par erreur)
* tu fait reposer une logique de travail sur une donnée qui peut être fausse et que tu peut être amené a changer (donc perdre ton intégrité des données).

Un id unique ça doit reposer sur un truc du système (l'idée du timestamp a la milliseconde est bonne dans le principe), si possible ne pas faire l'objet d'un encodage à la con super tordu pour ne pas bouffer des ressources pour rien (si tu fait reposer ça sur le système je vois pas l'utilité d'encoder).

Après, si encodage il doit y avoir c'est pour que la sortie soit normalisée en taille et format (ce qui peut aider a parser un fichier par exemple). Là Ok pourquoi pas un Hash mais de la à produire 100 000 caractères pour être sur de pas avoir de doublon là ou même MD5 réputé pouvoir apporter des collisions n'en produit pas a partir de chaines courtes ça frise l'insulte a la planète ... On est pas là pour faire tourner 12 centrale nucléaires afin de faire tourner une application qui de toute façon sera morte dans 10 ans :wink:

Le souci avec l'info c'est que parfois on garde plu les pieds sur terre.