Problème de gestion des droits d'accès sous Access 2003

Problème de gestion des droits d'accès sous Access 2003 - VB/VBA/VBS - Programmation

Marsh Posté le 28-04-2006 à 13:21:57    

Bonjour,
 
Ma question aujourd'hui, serait de savoir comme gérer des accès à des fonctionalité et à des données à des informations sur un formulaire ?
 
Il y a trois sortes de droits à gérer :
 
- Les droits (privilèges) : Administrateur, Création, Visualisation,
- La région d'appartenance : national, ou une parmi les 8 régions référencées,
- Le statut : Public, privé (les informations en public sont consultables par tout le monde, mais modifiables seulement par la région qui les a crées ou par l'administrateur).
 
Par avance je vous remercie.
 
Marco.
 


---------------
Marco
Reply

Marsh Posté le 28-04-2006 à 13:21:57   

Reply

Marsh Posté le 28-04-2006 à 14:05:18    

C'est tout simple, mais cela demande un peu de travail.
 
1. Récupérer l'identité de l'utilisateur
soit avec un formulaire demandant de s'identifier,
soit en récupérant une variable d'environnement
soit par un autre moyen
 
2. Avoir une table des privilèges associée à chaque utilisateur
ou associée à chaque profil d'utilisateur auquel cas il faut associer les utilisateurs à des profils.
 
3. Associer un privilège à chaque élément sensible (écran, accès en insertion, etc)
 
4. Contrôler avant chaque action sensible que l'utilisateur a le privilège requis.
 
Bon courage !

Reply

Marsh Posté le 28-04-2006 à 14:24:59    

Bonjour Olivthill,
 
Merci pour ta réponse. En fait je fais bien le (1) et le (2), mais mon problème est au niveau du (3) et du (4).
 
En fait il me semble que certains privilèges sont associés à des utilisateurs et d'autres aux données elles mêmes (public, privé).
 
Est ce que tu pourrais me donner un petit exemple et des indications un peut plus détaillées sur le (3) et (4), car en fait je récupère bien les infos des utilisateurs au début, à la connection, que transmets ensuites aux formulaires suivants (en désactivant ou rendant invisibles selon le cas certains contrôles en fonction du résultat). => sur les contrôles (bouttons...).
 
Par contre je ne sais pas triops comment gérer ça au niveau des données.  :??:  
 
Par avance je te remercie.
 
Marco.


---------------
Marco
Reply

Marsh Posté le 28-04-2006 à 14:50:08    

J'aimerais savoir si tu utilises les possibilités de sécurité internes d'Access 2003 ou si tu as développé ton propre système de gestion de droits ?

Reply

Marsh Posté le 28-04-2006 à 15:01:14    

Tout dépend comment l'applicatin est faite.
 
Voici quelques exemples à titre indicatif, mais on peut faire beaucoup d'autres choses
 
Pour gérer l'accès à un écran réservé à un administrateur

if (utilisateur = "admin" ) then
   DoCmd.OpenForm NomForm, acNormal...  
else
   MsgBox("Vous n'avez pas accès à cet écran" )
End If


Pour faire une requête qui ne montre que les données de la région de l'utilisateur

SQL_line="SELECT .... WHERE ..."
if (region_utilisateur = "Bourgogne" ) then
   SQL_line= SQL_line & " AND region='" & region_utilisateur"';"
Else
...
End If
Set rst = CurrentDb.OpenRecordset(SQL_line)
...


Pour désactiver ou cacher des boutons, ou d'autres éléments, on peut faire :

if (utilisateur = "admin" ) then
   Me.BoutonStat.Visible = True
   Me.ListePourUtilisateur.Enabled = False
...


Reply

Marsh Posté le 28-04-2006 à 17:16:18    

Bonjour,
 
En fait tegu, je n'utilise pas les possibilités de sécurisation d'Access 2003, pour la bonne raison que je ne les connais pas. :whistle:  
 
Est ce que tu pourrais me dire comment faire ? Pour le momment je récupère les infos du formulaire de connection et je les transmets aux écrans suivants et en fonction de ça (droits, région...), je cache ou pas certains bouttons et il faudra aussi que suivant le cas (information "publique" mais région différente de celle d'origine), je rende impossible la modification.
 
Ensuite il me restera quelques difficultés... Une partie de l'écran ne peut être modifiée que par un type de profil (droits = "création" et région = "national" )... Mais ceci est une autre histoire...
 
Par ailleur j'ai commencé à implémenter le système de olivthill.
 
Je suis preneur de tous les conseils possibles et surtout de savoir comment utiliser les "possibilités de sécurisation interne de Access 2003". Par avance merci pour tout.
 
Marco.


---------------
Marco
Reply

Marsh Posté le 02-05-2006 à 10:29:32    

Il me serait difficle de te décrire complètement le système de sécurisation Access 2003 car je ne l'ai jamais utilisé.
Mais il repose sur une structure habituelle en ce qui concerne la gestion des droits d'utilisateurs, à la manière de son grand frère Windows.
Tu peux donc créer des comptes utilisateur, des groupes de travail et associer des droits (accès, modif, exécution,...) aux objets (tables, requetes, états,...) à ces entités.
Cela nécessite un gros travail en amont pour définir le tout avant de le mettre en pratique. Et cela nécessite un minimum de documentation pour éviter de faire des bêtises (par exemple de verrouiller la base et ne plus y avoir accès soi-même).


Message édité par tegu le 02-05-2006 à 10:29:45
Reply

Marsh Posté le 02-05-2006 à 10:41:37    

Bonjour,
 
J'espère que vous avez tous passé un week end prolongé.
En fait j'ai bien mis en application ce qui a été décrit par olivthill. Mais il me manque à mettre en place les systèmes de sécurisation "internes" d'Access. A savoir, comment accéder en multiusers et depuis des sites différents à cette base de données...
 
Est ce que quelqu'un pourrait m'aider s'il vous plait ?
 
Par avance je vous remercie.
 
Marco un peut désespéré.


---------------
Marco
Reply

Marsh Posté le 02-05-2006 à 11:05:45    

Une solution, qui avait été adoptée dans l'entreprise où j'étais, consistait à séparer l'application en deux fichiers ".mdb".
 
Le premier contenait uniquement les tables. Ce fichier était placé sur un serveur, accessible par ping et ODBC.
 
Le second contenait tous les formulaires, tous les rapports d'éditions, tous les modules, toutes les requêtes, et des "tables "attachées" via des liens ODBC vers les tables du premier ".mdb". Ce fichier était placé sur chaque poste client.
 
Je suppose qu'il doit exister d'autres solutions.

Reply

Marsh Posté le 02-05-2006 à 11:29:28    

Merci olivtil,
 
Désolé pour le ton un peut "agressif" de mon précédent message, mais je craque un peut car ce point de la concurence des accès me fait beaucoups de soucis.
 
Existe t-il d'autres choses à mettre en oeuvre pour que ça marche ?
 
Mes utilisateurs sont sur des sites répartis sur toute la France je le rappelle.
 
Est ce qu'il existerait aussi (question subsidiaire) un moyen de faire en sorte de rendre paramétrable le nom du lecteur physique où est située la base (séparé comme tu l'as dit de l'application) ?
 
Par avance je te remercie.
 
Marco.


---------------
Marco
Reply

Marsh Posté le 02-05-2006 à 11:29:28   

Reply

Marsh Posté le 02-05-2006 à 11:48:52    

Pour tous mes développements sous Access je sépare les données pures, des formulaires/états et code.
Dans la base dite Programmes, je stocke dans une table Paramètres le chemin d'accès aux données.
Dans cette base Programmes je fais une liaison vers toutes les tables de la base Access dite de Données (option Lier les tables).
Cela me semble nécessaire, mais pas suffisant pour résoudre les problèmes de gestion de droits.
 
Cotmar, il va falloir que tu te lances. On ne peut pas te faire une formation en ligne sur ce forum et tu dois chercher de la doc sur les notions qu'on t'a suggérées.
 
MS Access est facile d'utilisation mais il ne faut pas croire que tout se fait en « deux coups de cuiller à pot », surtout quand on veut personnaliser son application et non plus se contenter des assistants.

Reply

Marsh Posté le 02-05-2006 à 12:21:00    

Merci Tegu pour tes réponses.
En fait je me suis bien lancé et j'ai essayé de tenir compte à plein de tous vos conseils à tous.
Les questions que je me posent sont celle qu'il me restent pour finir (sachant que les derniers formulaires sont assez rapides).
Je ne prétend pas que "tout se fait d'un coup de cuillère à pot". D'auilleur il m'a fallu un peut batailler avec ma chef ici pour rédiger une spec technique alors qu'elle disait justement que c'était quelquechose de facile et que "ça ne valait pas le coups". Ca a eu au moins le mérite d'isoler des incompréhensions et de lever certains problèmes techniques pour le réaliser concrêtement.
J'espère que je ne vous ai pas pris trops de temps.
A bientôt et bon apétit.
Marco.


---------------
Marco
Reply

Marsh Posté le 02-05-2006 à 15:10:03    

Si tu as réussis à rédiger une spec et fait passer l'idée que c'était pas aussi simple que ça, c'est déjà un bon début.
Si tu as des problèmes précis en cours de route, on essaiera de t'aider plus.

Reply

Marsh Posté le 22-02-2010 à 13:20:54    

olivthill a écrit :

C'est tout simple, mais cela demande un peu de travail.
 
1. Récupérer l'identité de l'utilisateur
soit avec un formulaire demandant de s'identifier,
soit en récupérant une variable d'environnement
soit par un autre moyen
 
2. Avoir une table des privilèges associée à chaque utilisateur
ou associée à chaque profil d'utilisateur auquel cas il faut associer les utilisateurs à des profils.
 
3. Associer un privilège à chaque élément sensible (écran, accès en insertion, etc)
 
4. Contrôler avant chaque action sensible que l'utilisateur a le privilège requis.
 
Bon courage !


Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed