Skip site navigation (1) Skip section navigation (2)

Re: Postgresql et les utilisateurs

From: Stephane BUNEL <stephane(at)stratum-ip(dot)net>
To: Alban <alban(dot)minassian(at)tele2(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Postgresql et les utilisateurs
Date: 2005-10-05 14:57:11
Message-ID: 4343E9C7.9000502@stratum-ip.net (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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



In response to

pgsql-fr-generale by date

Next:From: Jean-Max ReymondDate: 2005-10-05 15:54:38
Subject: Sun regarde Postgres !!
Previous:From: AlbanDate: 2005-10-05 13:03:32
Subject: Re: Postgresql et les utilisateurs

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group