Gestion approfondie des utilisateurs

Bonjour,
J'aimerai savoir si quelqu'un sais comment avec les "security" attribuer des droits autres que l'accès ou non aux XMLServices. cad, que j'aimerai pouvoir filtrer des données dans une table en fonction de l'utilisateur connecté.
Merci
Lux

C'est à toi que de modifier dynamiquement ta requête SQL en fonction de l'ID de l'utilisateur connecté. Utilises la syntaxe condensé des accolades. Par exemple :

Code:

---

1 2 3

SELECT MyTable.ID, MyTable.NAME FROM MyTable WHERE MyTable.USER_ID = {$ID_USER_CONNECTED}

---

Décris nous un peu plus ce que tu veux faire

Ca ressemble un peu a la question que j'ai poser sur le verrouillage d'un lien. Moi dans un menu j'affiche ou non des liens suivant si l'utilisateur appartient a un groupe admin ou non.
Pour cela je récupère le login de celui qui est connecté, j'inclu le fichier <projet>.Security.xml et je vérifie l'appartenance au groupe pour la personne qui est loggué soit :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

<xsl:for-each select="Security/Users/User"> <xsl:if test="Name = /document/XMLC_Params/XMLC_UserName"> <xsl:for-each select="Groups"> <xsl:if test="Group='39'"> <td> <a target="Main" href="{/document/Aliases/ModuleFicheDLL}FormCreatefiche"> <p> | Ajout fiche</p> </a> </td> </xsl:if> </xsl:for-each> </xsl:if> </xsl:for-each>

---

Je sais pas si cela répond a ta question mais sinon précise un peu.

En fait j'ai constitué une liste d’utilisateurs avec un accès filtré sur différent pays. Par exemple l’utilisateur « Boby » n’a la visibilité que sur les individus habitant les USA et le Canada, l’utilisateur « JR » n’a la visibilité que sur les individus habitant le Chili. Bien entendu cette liste peut évoluée avec le temps. C'est-à-dire que des nouveaux utilisateurs peuvent apparaître ou disparaître et que leurs droits peuvent évolués. La meilleure solution pour moi serait d’utiliser à 100% les « Security » d’XMLRAD mais je pense être obligé de passer par une table SQL regroupant les utilisateurs.

Le module "Security" d'XMLRAD permet de mettre en place un contrôle au niveau de l'accès de modules et/ou d'actions bien précis. Les groupes permettent de définir des rôles et d'accorder ou non aux utilisateurs, le droit d'éxécuter telle ou telle action.

Donc en effet, tu vas devoir gérer la sécurité par toi même dans la mesure où tu as une sécurité spécifique. Il te faudra surement maintenir une table de correspondance entre tes utilisateurs et la liste des pays auxquels ils ont accès. Soit tu fais ca dans une table d'une base de données, soit tu fais un fichier XML dans lequel tu stock toutes ces infos.. Si elles sont peu nombreuses, je te conseille le fichier XML..

Voilà !

Merci pour ces infos precieuses.
Je suis sur la voie, je vous tiens au courrant.
Lux.

Si ça peut intéresser quelqu’un. J’ai réglé mon problème de la manière suivante :
Je me suis servit de la propriété "Infos" attachée à chaque utilisateur et j’y ai mis les codes pays correspondants aux droits définis par mon client. Par exemple :
Pour Boby --> Infos : ‘US’ , ‘GB’, ‘F’
Pour JR --> Infos : ‘JP’, ‘ES’

En suite j’ai ajouté le code suivant dans ma dll qui me permet de récupérer la valeur de la propriété “Infos” pour un nom d’utilisateur donné :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

function TVinexpoProWebWM.GetUserInfo(UserName: String) : string; var FileName: string; SecurityDoc: IXMLCursor; User: IXMLCursor; begin FileName := XMLApplication.get_AppPath+'VinexpoProWeb.Security.xml'; SecurityDoc := TXMLCursor.Create; SecurityDoc.Load(FileName); User := SecurityDoc.Select('/Security/Users/*'); while not User.EOF do begin if User.GetValue('Name_') = UpperCase(UserName) then begin GetUserInfo := User.GetValue('Infos'); exit; end; User.Next; end; GetUserInfo := '''User not find !'''; end;

---

Puis dans mon événement « BeforeXMLGram » je construis ma requête dynamiquement avec notamment le morceau de code suivant :

Code:

---

QRY := QRY + ' AND V.CodePays IN ('+ GetUserInfo(Context.GetValue('XMLC_UserName'))+')';

---

Voilà, bon, c’est peut être pas bien élégant mais ça marche.
(JE SUIS CERTAIN QU’IL Y A PLUS SIMPLE ….)

Lux

BOOoouuuhhh !!! Il utilise un "IN" dans sa requête SQL !! Pouuuaaah !! 8O :D

Je pense que tu peux carrément modifier la grappe User, et rajouter tes propres sous-éléments spécifiques à tes besoins. Par exemple :

<USER>
<ID>15</ID>
<NAME>TOTO</NAME>
<INFOS>...</INFOS>
<COUNTRIES>US, UK, FR</COUNTRIES>
</USER>

En revanche il te faudra éditer le fichier Security à la main, puisque la propriété COUNTRIES sera inconnue de l'éditeur XMLRAD.

Qu'est ce qui cloche avec mon 'IN' ????
J'ai le sentiment d'avoir fait une enorme bétise :oops:

Par contre bien vu pour les ajouts de balises dans le fichier Security

Lux

Le IN n'as pas comme réputation d'être super performant.
Bon heureusement ce n'est pas un SubSelect qui est dans ton IN donc ca peut aller. Mais ne général on evite tant que possible.

Donc je remplace mon 'IN' par une suite de 'OR' ?

( Nous sortons ici un peu du forum XMLRAD milles excuses )

Lux

A toi de voir sur l'execution de la requête. Les OR peuvent aussi brassais pas mal d'enregistrements...