QGIS » ASGARD

Je ne reproduis pas.
A noter que GRANT ALL ON SCHEMA w_perso_michel TO g_gb_amin; ne sert à rien puisque g_gb_admin devient le propriétaire du schéma par l'event trigger sur CREATE.
PLutôt que GRANT USAGE ON schema l'esprit d'Asgard voudrait que tu déclares michel_p membre d'un groupe lecteur sur le schéma.
Mais en essayant de faire tes manip, moi j'ai bien sous db_manager 'cet utilisateur n'a aucun privilège sur une table importée ) ???

En fait, je ne sais pas si c'est un BUG de Qgis, mais si j'enregistre les identifiants mots de passe du profil alain_l, le comportement est correct, alain_l n'a pas accès à w_perso_michel.
Par contre, si je n'enregistre pas l'identifiant et mot de passe d'alain_l, qgis ne me les demande pas à la connexion et j'ai accès à tout..

DbManager,lui me demande l'identifiant et mot de passe et les droits sont respectés.

Pas très sûr de comprendre tes manip... si tu charges une couche dans QGIS il mémorise le rôle qui a effectué l'opération... tu peux le voir avec l'info-bulle en restant quelques secondes sur la couche... donc tu ne fais peut-être pas la manip avec le rôle que tu penses ?

ça donnerait effectivement l'impression que QGIS se connecte automatiquement avec le rôle postgres... dont tu as peut-être enregistré le mot de passe et l'identifiant dans les paramètres de connexion ?

Apparemment, ce serait plutôt un bug de Qgis qui, en mode SSL "désactive" ou "préfère", ne demande pas les identifiant/mot de passe lors de la connexion et donne l'accès aux tables.
Par contre en mode ""préfère", le schéma w_perso_michel n'est pas visible par alain_l.

La connexion via DbManager renvoie, lui, le message :
ERREUR: droit refusé pour le schéma w_perso_michel

Comment est-ce possible ? QGIS ne peut pas inventer tout seul les valeurs des paramètres username et password de la connexion et l'anomalie serait surtout du côté de PostgreSQL qui autorise une requête de connexion manifestement illégitime... Ce serait une énorme faille de sécurité.

Ou alors il faudrait que tu aies dans le pg_hba.conf de PostgreSQL une ligne disant que tu acceptes les connexions sans authentification ?
host all all 127.0.0.1/32 trust

Mais par défaut ça n'existe pas.

Autre possibilité, n'as-tu pas un fichier pgpass.conf quelque part (dans AppData) avec ton mot de passe enregistré pour le rôle postgres ? Ou des valeurs dans les variables d'environnement PGUSER et PGPASSWORD ?

Leslie Lemaire a écrit :

Comment est-ce possible ? QGIS ne peut pas inventer tout seul les valeurs des paramètres username et password de la connexion et l'anomalie serait surtout du côté de PostgreSQL qui autorise une requête de connexion manifestement illégitime... Ce serait une énorme faille de sécurité.

Ou alors il faudrait que tu aies dans le pg_hba.conf de PostgreSQL une ligne disant que tu acceptes les connexions sans authentification ?
host all all 127.0.0.1/32 trust

Mais par défaut ça n'existe pas.

Autre possibilité, n'as-tu pas un fichier pgpass.conf quelque part (dans AppData) avec ton mot de passe enregistré pour le rôle postgres ? Ou des valeurs dans les variables d'environnement PGUSER et PGPASSWORD ?

EDIT. Accessoirement, si tu est en localhost, c'est normal que tu n'accèdes pas aux données avec ssl requiere... puisqu'il est impossible d'établir une connexion SSL, quel que soit le rôle.

On peut supposer que si on ne change pas de session QGIS, QGIS s’emmêle les pinceaux et n'utilise pas la bonne connexion...
Pour le vérifier il faudrait relancer QGIS et voir si on a toujours accès...

Ok, je comprends mieux ce dont il était question.

Effectivement, dès lors que tu as saisi une fois ton identifiant et ton mot de passe pour la combinaison host-port-database-sslmode-[no user]-[no password], QGIS les garde en mémoire dans QgsCredentials.instance(). Tant que tu importes des couches dont l'URI contient les mêmes paramètres (toujours sans spécification d'user et/ou de password), il ne te redemande donc pas de t'authentifier. Et c'est une bonne chose, car sinon il faudrait ressaisir ton identifiant et ton mot de passe à chaque fois que tu touches à l'explorateur et ce serait l'horreur.

C'est l'un des problèmes qu'il y avait avec MenuBuilder, qui vidait QgsCredentials.instance() et obligeait l'utilisateur à se ré-authentifier après utilisation...

Mais effectivement, ça veut dire que si tu as défini dans QGIS deux connexions à ton serveur avec les mêmes [host]-[port]-[database]-[sslmode] sans enregistrer les mots de passe et identifiant, alors elles génèrent les mêmes URI, viseront la même instance de QgsCredentials.instance() et tu pourrais aussi bien n'en avoir qu'une. Pour dire les choses autrement, une connexion n'est pas identifiée par son nom, qui n'est là que pour l'affichage dans l'explorateur, mais par ses paramètres.

Et donc si tu veux changer de rôle de connexion en cours de route... sauf à vider à la main QgsCredentials.instance() via la console python, je ne vois pas non plus comment faire si ce n'est en relançant QGIS.

Je ne qualifierais pas ça de bug, plutôt de besoin fonctionnel non couvert par le système actuel (et peut-être pas tellement compatible avec lui, d'ailleurs).