Utiliser le modèle ADOX avec Visual Basic

Chaque objet a toujours un propriétaire. À l'origine, c'est le créateur de l'objet qui est le propriétaire.

Le propriétaire d'un objet garde le droit d'accès total (modification, suppression, droits) sur l'objet. Le propriétaire d'un objet peut être un utilisateur ou un groupe. La base de données est un objet un peu particulier puisque seul un utilisateur (et non un groupe) peut en être propriétaire.

Le problème de la gestion de la propriété est important à gérer si les utilisateurs ont le droit de créer des objets. Si vous souhaitez qu'ils gardent tous les droits sur les objets qu'ils ont créés, il n'y a rien à faire, mais sinon vous devez gérer le transfert de la propriété.

Faites toujours très attention à cette notion de propriétaire, elle peut permettre des accès que vous ne souhaiteriez pas si vous n'y prenez pas garde.

Habituellement, l'administrateur ou les membres du groupe administrateur sont les seuls à avoir tous les droits sur une base de données, y compris celui de modifier les droits d'accès des autres. De par ce fait, on essaye toujours de limiter le nombre d'administrateurs. Pour ce faire, il faut donc mettre au point une stratégie de droits pour que chaque groupe ait les droits nécessaires et suffisants à un bon fonctionnement. L'avantage dans ce cas d'une approche par programme est la possibilité d'utiliser une connexion ayant les droits administrateurs pour permettre aux utilisateurs de faire des actions (prévues) que leurs droits ne leurs permettraient pas de faire normalement.

XII-B-2-a. Access▲

C'est une notion classique de la sécurité des SGBD. Un groupe représente l'ensemble des utilisateurs possédant les mêmes droits. Un utilisateur représente en général une personne.

Chaque utilisateur appartient au minimum au groupe des utilisateurs, mais il peut appartenir à plusieurs groupes.

Un utilisateur hérite toujours des droits du(des) groupe(s) dont il dépend, mais peut avoir des droits modifiés par rapport à celui-ci. Attention, en cas de contradiction entre les droits du groupe et ceux de l'utilisateur, c'est toujours la condition la moins restrictive qui l'emporte.

Pour simplifier la gestion des droits, on définit habituellement les groupes puis les utilisateurs.

Lorsqu'un groupe est propriétaire, chaque utilisateur du groupe est également propriétaire.

L'héritage des droits d'un groupe est paramétrable.

Les droits d'un groupe / utilisateur se définissent normalement pour chaque objet.

Pour une base de données contenant de multiples objets, vous voyez immédiatement le code que cela peut engendrer. Il est possible de propager les droits d'un objet à tous les objets que celui-ci contient. Une solution consiste donc à donner des restrictions standards à l'objet base de données puis à adapter au cas par cas sur les objets. Attention, cette méthode n'est pas réversible, elle n'est donc pas sans risque. Cet héritage n'est jamais transverse, mais il est possible de définir des droits pour une catégorie générique d'objet.

Attribue les permissions sur un objet pour un groupe ou un utilisateur. De la forme

Group.SetPermissions Name, ObjectType, Action, Rights [, Inherit] [, ObjectTypeId]

Passons en revue ces paramètres, mais notez bien qu'ils s'appliquent aussi bien au groupe qu'à l'utilisateur. Les différences seront vues dans l'étude de l'objet User.

ObjectType▲

Name▲

Action▲

Rights▲

Inherit▲

ObjectTypeId▲

Permet de lire les autorisations d'accès d'un objet. Ce n'est pas toujours très simple à interpréter par programmation, aussi je vous conseille plutôt de supprimer puis de recréer les autorisations.

De la forme

ReturnValue = Group.GetPermissions(Name, ObjectType [, ObjectTypeId])

Ou ReturnValue est une valeur de type Long représentant le masque binaire. Pour tester si une autorisation existe dans le masque utiliser l'opérateur AND

La fonction suivante permet d'afficher les droits dans la fenêtre d'exécution.

Private Sub EcrisDroit(Droits As Long)

    If Droits And adRightCreate Then Debug.Print "Création"
    If Droits And adRightDelete Then Debug.Print "Effacement"
    If Droits And adRightDrop Then Debug.Print "Suppression"
    If Droits And adRightExclusive Then Debug.Print "Exclusif"
    If Droits And adRightExecute Then Debug.Print "Exécution"
    If Droits And adRightInsert Then Debug.Print "Insertion"
    If Droits And adRightRead Then Debug.Print "Lecture D"
    If Droits And adRightReadDesign Then Debug.Print "Lecture S"
    If Droits And adRightReadPermissions Then Debug.Print "LirePermission"
    If Droits And adRightReference Then Debug.Print "Reference"
    If Droits And adRightUpdate Then Debug.Print "Modification"
    If Droits And adRightWithGrant Then Debug.Print "ModifPermission"
    If Droits And adRightWriteDesign Then Debug.Print "Modif Structure"
    If Droits And adRightWriteOwner Then Debug.Print "Modif Prop"
End Sub

Avec un appel de procédure comme :

temp = MonGrou.GetPermissions("tblAnomalie", adPermObjTable)
Call EcrisDroit(temp)

Permet de modifier le mot de passe d'un utilisateur.

User.ChangePassword OldPassword, NewPassword

Là pas besoin d'explication si ce n'est qu'un des paramètres peut être la chaîne vide ""

S'utilise comme pour l'objet Group.

Comme je l'ai déjà dit, un utilisateur membre d'un groupe peut avoir des autorisations différentes de celles du groupe. Pour des raisons de maintenance, cette situation est toutefois à proscrire. N'oubliez pas que sur un mélange de propriétés utilisateur / groupe c'est toujours l'autorisation la moins restrictive qui l'emporte.

Les objets User et Group ont une collection properties.

Si la sécurité est déjà bien gérée, il ne s'agit que d'ajouter des utilisateurs et de bien gérer les droits d'accès ou de propriété. La technique consiste toujours à créer un utilisateur dans un groupe existant, afin de ne pas avoir à gérer tous ses droits objet par objet. Lors de la modification d'autorisations, il est souvent plus simple de détruire les anciennes, puis de réattribuer les autorisations. Cherchez toujours à donner la propriété des nouveaux objets à l'administrateur ou alors créez un utilisateur fantôme, appelé par exemple « Code », qui possède les autorisations nécessaires à tous vos accès par le code.

Si la sécurité est mal gérée, détruisez tout et repartez du début.

Le code suivant vous donne un exemple de la réattribution de la propriété des tables.

Private Sub Command9_Click()

Dim cnn1 As ADODB.Connection
Dim Catalogue As ADOX.Catalog, MaTable As ADOX.Table
    
    Set Catalogue = New ADOX.Catalog
    Set cnn1 = New ADODB.Connection
    With cnn1
        .Provider = "Microsoft.Jet.OLEDB.4.0;"
        .ConnectionTimeout = 30
        .CursorLocation = adUseClient
        .IsolationLevel = adXactChaos
        .Mode = adModeShareExclusive
        .Properties("Jet OLEDB:System database") = "D:\User\jmarc\tutorial\ADOX\system.mdw"
        .Open "Data Source=D:\User\jmarc\tutorial\ADOX\Test\NouvBase1.mdb ;User Id=Admin; Password=password"
    End With
    Catalogue.ActiveConnection = cnn1
    For Each MaTable In Catalogue.Tables
        If StrComp(Catalogue.GetObjectOwner(MaTable.Name, adPermObjTable), "admin", vbTextCompare) <> 0 And StrComp(Catalogue.GetObjectOwner(MaTable.Name, adPermObjTable), "engine", vbTextCompare) &lt;> 0 Then
            Catalogue.SetObjectOwner MaTable.Name, adPermObjTable, "Admin"
        End If
    Next

End Sub

Comme vous le voyez dans le test, n'essayez pas de prendre la propriété des tables dont le propriétaire est « engine » (information de schéma du moteur Jet) vous déclencheriez une erreur.

Lors de la création de la base, je vous conseille vivement de créer la sécurité en premier. Vous pouvez dès lors utiliser des objets génériques et définir vos droits assez rapidement. Il vaut toujours mieux avoir un groupe de trop que l'on supprime à la fin, plutôt que de se rendre compte qu'il en manque un.

Définissez votre système de sécurité avant de coder. Par le code il vaut mieux multiplier les groupes que les utilisateurs.

À partir d'Access 2000, vous pouvez contourner les faiblesses de ADO pour la création des utilisateurs et des groupes en utilisant le DDL. Sachez que celui vous permet de gérer les PID.

Un objet Command peut être utilisé avec une requête de type :

CREATE USER Nom MotDePasse PID

Mais nous sortons là du cadre de cet article