Dev Faq
8
votes

SharePoint 2007 - RunwithheEvatedprivileges - Des pièges d'utilisation de cette

J'ai un sentiment d'intestin fort que l'utilisation de SharePoint RunwithElevatedpriviluesges devrait être évitée comme la peste, mais doit convaincre d'autres pour savoir exactement pourquoi. Voici ce que j'ai.

  • apparaît un nouveau fil avec des privilèges élevés
  • bloque d'autres opérations jusqu'à ce que le délégué adopté revienne
  • Problèmes de sécurité (fonctionne avec un niveau élevé de privilèges, peut-être par un utilisateur final)
  • Autres?
0 commentaires

4 Réponses :

2
votes

rwep, comme tout le reste, avoir des avantages et des inconvénients.

Si vous êtes préoccupé par l'utilisateur final exécutant RWEP, vous avez probablement un problème plus gros, car ce code a déjà été installé sur GAC.

Parfois, il vous suffit de vous en tenir à cela: envisager un utilisateur qui n'a pas de droits d'administrateur, exécutant un flux de travail de document. Une fois cet utilisateur approuve (ou rejeter, peu importe), votre moteur de flux de travail doit être capable de redéfinir ce privilège Splistitem.

1 commentaires

Pourrait être une autre bonne raison d'éviter des privilées à travers. Sécurité d'accès au code. Ruben, pourriez-vous confirmer la source de l'exigence GAC?

0
votes

Je l'utilise et trouvez-le comme une fonctionnalité très utile. À mon avis, je choisis de laisser l'utilisateur exécuter mon code et de faire ce code que l'utilisateur ne pouvait normalement pas faire. Vous pouvez verrouiller quelque chose et laisser l'utilisateur l'accéder de manière très contrôlée.

1 commentaires

"Faire des choses" est très large. Pour accéder aux objets SharePoint, il convient de l'éviter. Suivez plutôt la suggestion de Dahlbyk d'une impersonnation SPSITE supprime les complexités de RunwithelevatedprivItiles En savoir plus à: Solution .NET / 2009/01 / 06 / Elegant-SpSite-Elevation

4
votes

1) L'utilisation substantielle de RWEP est une bonne indication des odeurs de code. Il peut être facilement abusé sans réfléchir, ce qui entraîne de graves problèmes de sécurité. De nombreux développeurs ne pensent pas à ce que les utilisateurs pouvaient faire avec le pouvoir qu'ils sont indirectement donnés «sous la hotte».

Un exemple: il est important d'appeler ValidateFormDigest avant d'utiliser rwep sur Demandes malveillantes dans les pages d'application .

2) Les objets SPWEB et SPSITE doivent être créés dans le contexte de RWEP. Ceci est facile pour les développeurs novices à oublier, menant à une grande frustration.

Cette restriction signifie également que tous les travaux et tous les objets créés par ces objets doivent être utilisés et terminés avec la fin du délégué du RWEP. C'est une autre erreur commune.

keith dahlby a écrit Méthodes d'extension pour contourner ces problèmes, donnant un code plus robuste et lisible.

1 commentaires

"Une bonne indication du code sent" - j'aime ça. Trop de mauvais nez ne fonctionnent pas pour ça aussi. ;)

15
votes

raisons d'élever tomber en deux catégories:

  1. Votre code doit effectuer des opérations dans SharePoint pour lequel l'utilisateur actuel n'a pas d'autorisations. Cela devrait toujours être fait tout en travaillant avec la sécurité SharePoint, non comme une mesure "juste au cas" qui indique que vous devez mieux comprendre votre situation de sécurité.
  2. Votre code doit accéder aux ressources externes (système de fichiers de serveur, base de données, partage de fichiers, etc.) sur lequel l'identité du pool d'applications a accès mais l'utilisateur actuel ne le fait pas.

    Pour le premier, vous êtes beaucoup mieux en utilisant Impanonation SPSITE . Ce dernier est la seule raison pour laquelle j'utilise jamais RWEP.

    Pour clarifier, RWEP n'apparaît pas un nouveau fil. Au lieu de cela, il utilise des API Win32 pour revenir à l'identité du thread actuel à l'identité de processus (désactivation de l'impersonnation) pour exécuter le code élevé, puis basculez l'impersonnation pour reprendre le travail pour le compte de l'utilisateur actuel. Cela a plusieurs implications:

    1. RWEP ne fait rien si le fil n'est pas imités, il est donc inutile dans les travaux de minuterie, les flux de travail Visual Studio, les applications de console et le code exécuté via Stsadm (récepteurs de fonctionnalités).
    2. Accès à SharePoint, en supposant que vous créez une nouvelle spsite dans votre codeOrunEnEvated, sera effectuée avec les droits du pool d'applications (SharePoint \ System). Ce compte aura un accès complet à l'application Web actuelle, mais ne doit pas avoir des autorisations de niveau de la ferme pour faire des choses comme modifier les propriétés SPFARM ou modifier le SSP.
    3. Utiliser des objets sensibles à l'identité (comme SPSITE et ses enfants) sur les limites d'exécution de votre codeOrunEnEvated a le potentiel de causer un comportement et des conditions de course vraiment géniaux. À toutes fins utiles, considérez ce problème non pris en charge.

      Et comme l'a dit Alex, les enfants d'un SPSITE héritent de leurs autorisations du SPSITE, ce qui a à son tour ses autorisations définies lors de sa création. Donc, SPContext.Current.Site se comportera toujours avec les autorisations de l'utilisateur actuel, même si vous y référez-le dans votre codeOrUnEnveated. Au lieu de cela, vous aurez besoin de créer et de consommer une nouvelle spsite dans le bloc élevé.

      Pour résumer: RWEP pour imiter le bassin d'applications en dehors de SharePoint, une impersonnation SPSITE pour imiter le pool d'applications à l'intérieur de SharePoint.

2 commentaires

bonne réponse. Pourriez-vous élaborer pourquoi son emploi inutile dans des emplois de minuterie, etc.?

Les applications Web SharePoint utilisent l'impersonnation pour exécuter le code car l'utilisateur qui est signé - RWEP désactive temporairement cette impersonnation sur un thread. Si le code ne s'exécute pas avec l'impersonnation pour commencer, comme dans une application de minuterie ou de console, l'utilisateur de l'utilisateur de thread et l'utilisateur du processus ("utilisateur élevé" de RWEP) sont les mêmes.

Articles qui pourrait vous intéresser :

 Serliog Sinks: la lecture de la configuration json ne fonctionne pas
Ajouter Blazor côté client à l'application ASP.NET MVC5 existante
Comment puis-je configurer des dispositions conditionnelles avec _ViewStart dans ASP.NET Core Razor Pages?
Le type ou le nom d'espace de noms «Mvc» n'existe pas dans l'espace de noms «Microsoft.AspNetCore» (vous manquez une référence d'assembly?)