Re: Postgresql et les utilisateurs

Bonjour Alban,

Je crois que la solution la plus simple est:
1- d'avoir un seul usager PostgreSQL qui peut se connecter a la base de
donnees ce qui enleve la possibilite aux usagers d'aller voir les todos des
autres a l'aide de pgAdmin par exemple. Naturellement cet usager doit etre
connu que par 1 ou 2 personnes de confiance.
2- d'avoir une table dans la base de donnees qui contient tes usagers avec
leur mot de passe.
3- ton application accede a la base de donnees en utilisant l'usager defini en
1 mais doit s'occuper de verifier si l'usager a le droit de regarder les
todos a l'aide d'un select dans la table des usagers de la base de donnees.
4- ton application ne doit pas etre connecte a la base tout le temps si plus
de 100 usagers peuvent utiliser la base simultanement.

Pour ton information, la limite de 100 usagers dans PostgreSQL est directement
lie a la memoire partagee disponible sur ton systeme. C'est donc une limite
relie au systeme d'exploitation lui-meme et non pas a PostgreSQL.
D'apres-moi une limite similaire existe avec Oracle et est fort probablement
plus basse que celle de PostgreSQL. En passant, la limite de 100 usagers est
pour 100 usagers simultanes. Donc tu peu avoir des milliers d'usagers
potentiels en autant qu'il n'y a pas plus que 100 usagers simultanes.

Pour l'article que tu mentionnes pour le "Row Level Security" cela ne me
semble pas s'appliquer a ton cas puisqu'il s'agit d'empecher les "update" et
"delete" et non pas les "select".

Juste mon petit grain de sel.

Salutations,

Bernard

PS Excuses s'il n'y a pas d'accent dans ma reponse mais je travaille
normallement qu'en anglais.

On Wednesday 05 October 2005 07:24, Alban wrote:
> C'est pour développer une application classique (c++/qt ou c/gtk)
> client-serveur interne à un réseau (sans serveur apache ou tomcat
> intermédiare) qui accède directement à la base de données. Cette
> application serait de type gestion des todos. Chaque personne se
> connecte avec un login et un mot de passe (cf pg_shadow) et accède à une
> table 'todo' avec les champs 'todo' et 'user'. La colonne 'user' est
> égal à un login existant dans pg_shadow. Les utilisateurs ne peuvent
> accéder qu'a leur propre todo.
>
> >>, mais je ne suis pas certain que, ce soit la bonne manière
>
> d'authentifier les gens, je suis plus tenté de penser qu'un seul compte
> qui se connecte et ensuite authentifier les utilisateurs depuis une
> table de la dite base me paraît mieux.
>
> >>Ne vaudrait-il pas mieux factoriser ces utilisateurs pour arriver
>
> plutôt à une gestion de rôles comme le propose la future 8.1 ?
>
> Si je définie un seul et unique rôle (ou groupe pour rester dans la
> version 8.0) qui est autorisé à effectuer des selects sur la table todo,
> je dois croiser les doigts pour que les utilisateurs n'utilisent que
> l'application que je développe (et qui effectuera les requêtes du genre
> 'select * from todo where user = loginDeConnexion') ... car n'importe
> qui peut lancer/utiliser pgAdmin et lancer la requête manuellement sur
> la table 'todo' et lire les todos des autres.
>
> L'autre solution est de reprendre le concept Row Level Security (
> http://www.varlena.com/varlena/GeneralBits/77.php) que je trouve
> intéressante.
>
> >> une partie de pg_shadow est stoqué dans un fichier texte,
>
> PGDIR/data/global/pg_pwd Je ne saurais dire si ça monte bien en charge
>
> Intéressant comme information, mais alors quelle est la limite où
> postgresql s'essoufle réellement ? J'ai du mal à comprendre qu'une base
> de données 'professionelle' comme postgresql ne saurait gérer qu'une
> centaine d'user. Quel sont les limites d'Oracle dans ce domaine ?
>
>
> Est-ce que Postgresql est peut facilement gérer plusieurs milliers
> (chiffre volontairemnt provocateur) d'user sans probème ?
>
> Cordialement
> Alban
>
> Alban wrote:
> > J'utilise postgresql comme base de donnée et pour information
> > (j'insiste) j'aimerais savoir si cette base de donnée est adaptée pour
> > gérer plusieurs (centaine de) milliers d'utilisateurs : chacun avec un
> > login et un mot de passe différent ( et donc dans la table pg_shadow)
> > . Quels sont les limites de postgresql dans ce domaine, quel autres
> > solutions je dois envisager pour mettre en place une telle demande ?
> > Avez vous des url ou des pistes à me conseiller, des implentations
> > déjà mises en oeuvre ...
> >
> > Merci d'avance de votre aide.
> > Cordialement
> > Alban
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend