Re: Postgresql et les utilisateurs

Bonjour,

L'essentiel c'est de participer...

Pour ma part, je procède avec une architecture N-Tier :
L'application cliente n'a JAMAIS accès à la base de donnée en direct.
Mes principales raisons :
- Non "scalable"
- Choix du SGBDR figé
- Distribution des librairies du SGBDR et installation (versionning)
- Constitution / gestion de Meta-Base quasi impossible
- Pas confiance en ce que peux faire le client

L'application cliente communique avec un "middleware" qui pour mon cas
est un "service web" (expression à la mode). Donc, un simple apache et
de l'intelligence métier écrite en Python.

C'est le "service web" qui fait les accès à la(les) base(s) de données,
traite les données et les retourne à l'application cliente.

Bien-sûr c'est un peu plus complexe a mettre en place mais c'est le prix
de la commodité. L'application cliente fait des appels de type RPC
(SOAP/REST/XMLRPC...) sur le middleware ce qui permet de placer
l'intelligence métier au plus près des données, loin, très très loin du
client qui n'est qu'un afficheur interactif (View du modèle MVC).

De fait, une modification coté règles métier se retrouve déployée
automatiquement. Ce n'est pas toujours sans contraintes, il n'y a rien
de parfait.

myContrib.

Stéphane.

Alban a écrit :
> Merci pour vos analyses
>
> Si je résume, on peut ajouter des (centaines) milliers d'utilisateurs
> dans pg_shadow, mais seul X utilisateurs peuvent se connecter à la fois
> ( X = limites matérielles du serveur)
>
> J'ai toujours un petit problème avec la proposition de Bernard car les
> applications clientes vont contenir le login et le password (certe en
> hexa etc ..) de la personne de confiance. C'est un peu comme si je
> disais au client : rassurez vous j'ai masqué le login et le password de
> 'root' ou 'postges' dans chaque application. Et puis y a ces problèmes :
> Si j'écris dans un fichier ini (ou base de registre) et même codé(md5,
> etc) ... la sécurité n'est pas assuré
> Si j'écris en dur dans le code de l'application ou dans un fichier ini,
> tout changement de login/password nécessite de redéployer tous les
> applications.
>
> tzacos : pour complement d'information, pg_shadow est t'elle une vrai
> table (c'est a dire aussi 'rapide' qu'une table créé à la mano nommé par
> exemple 'users') ou un simple fichier texte, ou les deux à la fois (et
> comment ca fonctionne?). Car dans le fichier pg_pwd je lis les
> informations "user" et "password", mais la doc
> http://traduc.postgresqlfr.org/pgsql-8.0.3-fr/catalog-pg-shadow.html
> indique que la table contient toutes ces informations ... que viens
> faire ce fichier pg_pwd ?
>
> L'architecture N-tiers est intéressante mais ca oblige à administrer les
> droits des users côté sgbd et apache/php, de créer une fause table user
> : regrouper l'administration des users dans la base de données (et dans
> une seule table pg_shadow) me semble/ait naturel.
>
> Au plaisir de vous lire
> Alban
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly