Comment créer une chaîne aléatoire adaptée à un ID de session dans PostgreSQL?

Je voudrais créer une chaîne aléatoire à utiliser dans la vérification de session à l'aide de PostgreSQL. Je sais que je peux obtenir un nombre aléatoire avec SELECT random(), alors j'ai essayé SELECT md5(random()), mais cela ne fonctionne pas. Comment puis-je faire ceci?

Je suggérerais cette solution simple:

C'est une fonction assez simple qui renvoie une chaîne aléatoire de la longueur donnée:

Create or replace function random_string(length integer) returns text as
$$
declare
  chars text[] := '{0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z}';
  result text := '';
  i integer := 0;
begin
  if length < 0 then
    raise exception 'Given length cannot be less than 0';
  end if;
  for i in 1..length loop
    result := result || chars[1+random()*(array_length(chars, 1)-1)];
  end loop;
  return result;
end;
$$ language plpgsql;

Et l'utilisation:

select random_string(15);

Exemple de sortie:

select random_string(15) from generate_series(1,15);

  random_string
-----------------
 5emZKMYUB9C2vT6
 3i4JfnKraWduR0J
 R5xEfIZEllNynJR
 tMAxfql0iMWMIxM
 aPSYd7pDLcyibl2
 3fPDd54P5llb84Z
 VeywDb53oQfn9GZ
 BJGaXtfaIkN4NV8
 w1mvxzX33NTiBby
 knI1Opt4QDonHCJ
 P9KC5IBcLE0owBQ
 vvEEwc4qfV4VJLg
 ckpwwuG8YbMYQJi
 rFf6TchXTO3XsLs
 axdQvaLBitm6SDP
(15 rows)

Vous pouvez corriger votre tentative initiale comme ceci:

SELECT md5(random()::text);

Beaucoup plus simple que certaines des autres suggestions. :-)

En vous basant sur la solution de Marcin, vous pouvez le faire pour utiliser un alphabet arbitraire (dans ce cas, les 62 caractères alphanumériques ASCII):

SELECT array_to_string(array 
       ( 
              select substr('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789', trunc(random() * 62)::integer + 1, 1)
              FROM   generate_series(1, 12)), '');

Vous pouvez obtenir 128 bits aléatoires à partir d'un UUID. C'est la méthode pour faire le travail dans PostgreSQL moderne.

CREATE EXTENSION pgcrypto;
SELECT gen_random_uuid();

           gen_random_uuid            
--------------------------------------
 202ed325-b8b1-477f-8494-02475973a28f

Cela vaut peut-être la peine de lire la documentation sur l'UUID aussi

Le type de données uuid stocke les identifiants universellement uniques (UUID) tels que définis par RFC 4122, ISO / CEI 9834-8: 2005 et les normes associées. (Certains systèmes se réfèrent à ce type de données comme un identifiant global unique, ou GUID, à la place.) Cet identifiant est une quantité de 128 bits qui est générée par un algorithme choisi pour rendre très improbable que le même identifiant soit généré par quelqu'un d'autre dans l'univers connu en utilisant le même algorithme. Par conséquent, pour les systèmes distribués, ces identifiants offrent une meilleure garantie d'unicité que les générateurs de séquence, qui ne sont uniques qu'au sein d'une seule base de données.

Dans quelle mesure une collision avec l'UUID est-elle rare ou devinable? En supposant qu'ils sont aléatoires,

Environ 100 trillions d'UUID version 4 devraient être générés pour avoir 1 chance sur un milliard d'un seul doublon («collision»). La probabilité d'une collision augmente à 50% seulement après que 261 UUID (2,3 x 10 ^ 18 ou 2,3 ​​quintillions) ont été générés. En associant ces nombres aux bases de données et en considérant la question de savoir si la probabilité d'une collision d'UUID de la version 4 est négligeable, considérez un fichier contenant 2,3 quintillions d'UUID de la version 4, avec une probabilité de 50% de contenir une collision d'UUID. Ce serait une taille de 36 exaoctets, en supposant qu'aucune autre donnée ou surcharge, des milliers de fois plus grandes que les plus grandes bases de données actuellement existantes, qui sont de l'ordre du pétaoctet. Au taux de 1 milliard d'UUID générés par seconde, il faudrait 73 ans pour générer les UUID du fichier. Il en faudrait également environ 3. 6 millions de disques durs ou de cartouches de bande de 10 téraoctets pour le stocker, sans sauvegarde ni redondance. La lecture du fichier à un taux de transfert "disque à tampon" typique de 1 gigabit par seconde nécessiterait plus de 3000 ans pour un seul processeur. Étant donné que le taux d'erreur de lecture irrécupérable des lecteurs est de 1 bit pour 1018 bits de lecture, au mieux, alors que le fichier contiendrait environ 1020 bits, le simple fait de lire le fichier une fois de bout en bout entraînerait, au moins, environ 100 fois plus de problèmes. lire les UUID que les doublons. Les erreurs de stockage, de réseau, d'alimentation et autres erreurs matérielles et logicielles seraient sans aucun doute des milliers de fois plus fréquentes que les problèmes de duplication d'UUID. un taux de transfert de 1 gigabit par seconde nécessiterait plus de 3000 ans pour un seul processeur. Étant donné que le taux d'erreur de lecture irrécupérable des lecteurs est de 1 bit pour 1018 bits de lecture, au mieux, alors que le fichier contiendrait environ 1020 bits, le simple fait de lire le fichier une fois de bout en bout entraînerait, au moins, environ 100 fois plus de problèmes. lire les UUID que les doublons. Les erreurs de stockage, de réseau, d'alimentation et autres erreurs matérielles et logicielles seraient sans aucun doute des milliers de fois plus fréquentes que les problèmes de duplication d'UUID. un taux de transfert de 1 gigabit par seconde nécessiterait plus de 3000 ans pour un seul processeur. Étant donné que le taux d'erreur de lecture irrécupérable des lecteurs est de 1 bit pour 1018 bits de lecture, au mieux, alors que le fichier contiendrait environ 1020 bits, le simple fait de lire le fichier une fois de bout en bout entraînerait, au moins, environ 100 fois plus de problèmes. lire les UUID que les doublons. Les erreurs de stockage, de réseau, d'alimentation et autres erreurs matérielles et logicielles seraient sans aucun doute des milliers de fois plus fréquentes que les problèmes de duplication d'UUID.

source: wikipedia

En résumé,

• L'UUID est normalisé.
• gen_random_uuid()correspond à 128 bits d'aléa stockés sur 128 bits (2 ** 128 combinaisons). 0-déchet.
• random() ne génère que 52 bits d'aléa dans PostgreSQL (2 ** 52 combinaisons).
• md5()stocké comme UUID est de 128 bits, mais il ne peut être aussi aléatoire que son entrée ( 52 bits si vous utilisezrandom() )
• md5()stocké sous forme de texte est de 288 bits, mais il ne peut être aussi aléatoire que son entrée ( 52 bits si vous utilisezrandom() ) - plus de deux fois la taille d'un UUID et une fraction du caractère aléatoire)
• md5() en tant que hachage, peut être tellement optimisé qu'il ne fait pas grand chose.
• L'UUID est très efficace pour le stockage: PostgreSQL fournit un type qui est exactement de 128 bits. Contrairement à textet varchar, etc. qui stockent comme un varlenaqui a une surcharge pour la longueur de la chaîne.
• L'UUID astucieux de PostgreSQL est fourni avec des opérateurs, des castings et des fonctionnalités par défaut.

Je jouais avec PostgreSQL récemment, et je pense avoir trouvé une solution un peu meilleure, en utilisant uniquement des méthodes PostgreSQL intégrées - pas de pl / pgsql. La seule limitation est qu'il ne génère actuellement que des chaînes UPCASE, des nombres ou des chaînes en minuscules.

template1=> SELECT array_to_string(ARRAY(SELECT chr((65 + round(random() * 25)) :: integer) FROM generate_series(1,12)), '');
 array_to_string
-----------------
 TFBEGODDVTDM

template1=> SELECT array_to_string(ARRAY(SELECT chr((48 + round(random() * 9)) :: integer) FROM generate_series(1,12)), '');
 array_to_string
-----------------
 868778103681

Le deuxième argument de la generate_seriesméthode dicte la longueur de la chaîne.

Veuillez utiliser string_agg!

SELECT string_agg (substr('abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789', ceil (random() * 62)::integer, 1), '')
FROM   generate_series(1, 45);

J'utilise ceci avec MD5 pour générer également un UUID. Je veux juste une valeur aléatoire avec plus de bits qu'un random ()entier.

Bien qu'il ne soit pas actif par défaut, vous pouvez activer l'une des extensions principales:

CREATE EXTENSION IF NOT EXISTS pgcrypto;

Ensuite, votre instruction devient un simple appel à gen_salt () qui génère une chaîne aléatoire:

select gen_salt('md5') from generate_series(1,4);

 gen_salt
-----------
$1$M.QRlF4U
$1$cv7bNJDM
$1$av34779p
$1$ZQkrCXHD

Le premier nombre est un identifiant de hachage. Plusieurs algorithmes sont disponibles chacun avec leur propre identifiant:

• md5: 1 $
• bf: 2 $ a 06 $
• des: pas d'identifiant
• xdes: _J9 ..

Plus d'informations sur les extensions:

• pgCrypto: http://www.postgresql.org/docs/9.2/static/pgcrypto.html
• Extensions incluses: http://www.postgresql.org/docs/9.2/static/contrib.html

ÉDITER

Comme indiqué par Evan Carrol, à partir de la v9.4, vous pouvez utiliser gen_random_uuid()

http://www.postgresql.org/docs/9.4/static/pgcrypto.html

Je ne pense pas que vous recherchiez une chaîne aléatoire en soi. Ce dont vous auriez besoin pour la vérification de session, c'est une chaîne qui est garantie d'être unique. Stockez-vous les informations de vérification de session pour l'audit? Dans ce cas, vous avez besoin que la chaîne soit unique entre les sessions. Je connais deux approches assez simples:

1. Utilisez une séquence. Bon pour une utilisation sur une seule base de données.
2. Utilisez un UUID. Universellement unique, si bien sur les environnements distribués aussi.

Les UUID sont garantis uniques en vertu de leur algorithme de génération; en fait, il est extrêmement improbable que vous génériez deux nombres identiques sur n'importe quelle machine, à tout moment, jamais (notez que c'est beaucoup plus fort que sur des chaînes aléatoires, qui ont une périodicité beaucoup plus petite que les UUID).

Vous devez charger l'extension uuid-ossp pour utiliser les UUID. Une fois installé, appelez l'une des fonctions uuid_generate_vXXX () disponibles dans vos appels SELECT, INSERT ou UPDATE. Le type uuid est un nombre de 16 octets, mais il a également une représentation sous forme de chaîne.

Le paramètre INTEGER définit la longueur de la chaîne. Garanti pour couvrir les 62 caractères alphanum avec une probabilité égale (contrairement à certaines autres solutions flottant sur Internet).

CREATE OR REPLACE FUNCTION random_string(INTEGER)
RETURNS TEXT AS
$BODY$
SELECT array_to_string(
    ARRAY (
        SELECT substring(
            '0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
            FROM (ceil(random()*62))::int FOR 1
        )
        FROM generate_series(1, $1)
    ), 
    ''
)
$BODY$
LANGUAGE sql VOLATILE;

@Kavius ​​a recommandé d'utiliser pgcrypto, mais au lieu de gen_salt, qu'en est-il gen_random_bytes? Et que diriez-vous sha512au lieu de md5?

create extension if not exists pgcrypto;
select digest(gen_random_bytes(1024), 'sha512');

Documents:

F.25.5. Fonctions de données aléatoires

gen_random_bytes (count integer) renvoie bytea

Renvoie le nombre d'octets aléatoires cryptographiquement forts. Au plus 1024 octets peuvent être extraits à la fois. Ceci permet d'éviter de vider le pool du générateur de aléas.

select * from md5(to_char(random(), '0.9999999999999999'));

select encode(decode(md5(random()::text), 'hex')||decode(md5(random()::text), 'hex'), 'base64')