Hum, j'ai réussi a résoudre

Makkhdyn/ = 20 Août, 2007 - 11:46

Hum, j'ai réussi a résoudre ma seconde question grace à SECURITY DEFINER lors de la création de la fonction.
Maintenant il ne me reste plus que le premier problème qui était pour résumer, "est-ce mieux d'enregistrer les utilisateurs de mon application dans une table "users" spéciale, ou bien dans pg_user?" tout en sachant qu'il est sencé y avoir énormément d'utilisateurs.
(Ça m'arrangerais que ça soit mieux de passer par pg_user.)

Bonjour

Christophe Chauvet/ = 21 Août, 2007 - 11:21

Bonjour

On est toujours tenter lorsque l'on créer un programme de gérer soit même sa gestion des utilisateurs dans une tables séparée. on peut bien sur se basé sur le système de rôles introduit dans la 8.1 donc un article est dispo ici.

pour ma part voici comment je procède
- je crée une table utilisateur qui contient les infos de mes utilisateurs (login/pass/nom/prenom/mail,etc....)
- je crée un rôle CNX avec avec l'attribut LOGIN et celui n'a accès en SELECT qu'a ma table contenant les utilisateurs (il me sert seulement à verifier le login mot de passe et récupérer le rôle de base de cette utilisateur).
- ensuite j'effectue un SET ROLE nom_role_utilisateur
- il faut bien sur définir dans votre cas un rôle pour chaque utilisateurs, et définir aussi les droit de chaque rôle sur les tables.
(vous pouvez pour cela definir des rôles génériques dont vos rôles utilisateurs hériteront.

j'utilise l'utilisateur de connexion CNX car on laisse sur le poste des utilisateurs (dans le cas d'application locale) les login/pass en clair dans les fichiers de config, cela s'apparente a des failles de sécurités, dans notre cas cette utilisateur n'a accès qu'a la table de gestion des utilisateurs en SELECT, il faut bien sur crypter les mot de pass dans cette base (MD5 par ex) pour éviter à une personne malveillante de récupérer un couple login/pass et de se connecter également à l'applicatif.

Cordialement.

Christophe Chauvet
KrysKool.org

Merci pour cette solution.

Makkhdyn/ = 21 Août, 2007 - 20:25

Merci pour cette solution.

Ça m'a permit de découvrir les rôles (jusqu'a présent je passais pas les users et groupes normaux...).
Cependant je ne comprends pas vraiment l'interet de passer par un rôle CNX.
En effet passer par CNX signifie que l'user se loggue envoie son mot de passe au serveur et change de rôle. Et ce a chaque connection.
N'est il pas plus simple de se logguer directement (donc d'avoir tous les "SET ROLE nom_role_utilisateur" avec l'attribut login) ?

Peu importe le cas, que ça soit en stockant les logins/pass d'accès a la BDD ou les logins/pass de connection en tant que tel ou tel utilisateur, le défaut au niveau sécurité est le même.
Qui plus est, ne peut-on pas stocker le pass de connection à la BDD au format md5 ?
Si l'on sécurise les accès, lors de la création d'un role, on spécifie "ENCRYPTED" ou mieux, on active "password_encryption" dans la config du serveur, plus besoin de stocker de mots de passes en clair.

Sinon pour ce qui est de CNX, inutile de lui donner les droits SELECT, il suffit de créer (ce qui était mon second problème que j'ai réussi a résoudre) une fonction qui fait la vérification et de lui donner le mode "SECURITY DEFINER".