FAQ Sharepoint
Sommaire
>
Outils et développement >
Sécurité Dynamique
Comment lister les utilisateurs faisant partie d'un groupe?
Comment ajouter un groupe dynamiquement dans la sécurité d'un site?
Comment ajouter un utilisateur dans un groupe?
Comment attribuer un rôle (permission level) à un utilisateur?
Comment attribuer un rôle (permission level) à un groupe?
Comment supprimer un utilisateur d'un groupe?
Comment supprimer un groupe?
Comment associer un groupe ou un utilisateur dans la sécurité d'un élément de liste dynamiquement?
Comment casser l'héritage automatique en utilisant des permissions uniques?
Comment exécuter une portion de code avec une autre identité?
Comment n'obtenir que la liste que l'utilisateur courant peut accéder?
Comment savoir si l'utilisateur courant peut lire, écrire dans une liste?
Comment lister les utilisateurs faisant partie d'un groupe?
Comment ajouter un groupe dynamiquement dans la sécurité d'un site?
Comment ajouter un utilisateur dans un groupe?
Comment attribuer un rôle (permission level) à un utilisateur?
Comment attribuer un rôle (permission level) à un groupe?
Comment supprimer un utilisateur d'un groupe?
Comment supprimer un groupe?
Comment associer un groupe ou un utilisateur dans la sécurité d'un élément de liste dynamiquement?
Comment casser l'héritage automatique en utilisant des permissions uniques?
Comment exécuter une portion de code avec une autre identité?
Comment n'obtenir que la liste que l'utilisateur courant peut accéder?
Comment savoir si l'utilisateur courant peut lire, écrire dans une liste?
| ||
auteur : Stephane Eyskens | ||
Notez que lorsqu'il est possible d'éviter un foreach, c'est préférable. Vous auriez donc pu
utiliser cette boucle
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
|
| ||
auteur : Stephane Eyskens | ||
Comme vous le savez déjà, l'héritage automatique est d'application lorsque vous créez un objet dans
Sharepoint. La sécurité définie au niveau de l'élément conteneur est implicitement appliquée à l'élément
que l'on vient de créer. Si vous devez systématiquement modifier ce comportement afin d'appliquer
des permissions uniques à chaque fois qu'un élément se crée et en fonction de critères spécifiques (métadonnées), vous
pouvez le faire au travers d'un event handler, ou d'un workflow qui se déclenche automatiquement.
Voici un exemple montrant comment casser l'héritage
|
| ||
auteur : Stephane Eyskens | ||
Habituellement, si du code s'exécute au sein d'un workflow ou d'un event handler, c'est sous
l'identité du visiteur qui a déclenché l'action, du moins en ce qui concerne les accès aux objets
Sharepoint. Ce comportement est bien sûr cohérent et souhaitable. Cependant, il est parfois nécessaire
de pouvoir exécuter du code quelles que soient les permissions du visiteur courant. Ceci se vérifie
lorsque l'on souhaite attribuer une sécurité particulière sur un élément de liste que l'utilisateur de type
"contributeur" vient de créer mais dont il n'a pas le droit de gérer la sécurité.
Donc, si dans un Event Handler on modifie les permissions de tous les éléments au moment de leur création, il faut
pouvoir le faire et ce, même si l'utilisateur courant n'a pas les droits requis pour gérer les autorisations.
RunWithElevatedPrivileges permet d'exécuter la portion de code que l'on y encapsule dans un
contexte de sécurité différent qui autorise le full control. Par contre, tous les objets que l'on
y manipule doivent être créés au sein de l'encapsulation. On ne pourra pas utiliser SPContext.Current.Web
avec des droits full control car il n'a pas été créé dans le délégué.
|
| ||
auteur : Stephane Eyskens | ||
Plutôt que de passer par la méthode "AllWebs" qui tente de retourner une collection de
TOUS les sous-sites du site courant, il est préférable d'utiliser une autre méthode si votre
code est susceptible d'être exécuté sous l'indentité d'un tiers. En effet AllWebs retournera
une erreur de type Access Denied/Accès Refusé si l'utilisateur courant n'a pas accès à l'un des
sous-sites.
Vous l'aurez compris, GetSubwebsForCurrentUser() évite toute erreur d'accès quel que soit
l'utilisateur connecté
|
| ||
auteur : Stephane Eyskens | ||
Imaginons qu'on soit dans le contexte d'un webpart, on pourrait tester si l'utilisateur courant a le droit
d'écrire dans une liste de cette manière:
SPBasePermissions permet de tester tous les types de permissions.
|