Parfois, les applications asp.net que nous écrivons s'exécutent sur des hôtes virtuels. Certains hôtes virtuels peuvent avoir défini des autorisations sur asp.net pour des raisons de sécurité, ce qui empêchera nos applications de fonctionner correctement.
Symptômes du problème :
Pour une raison quelconque, asp.net ne peut pas charger certains fichiers dll et le message d'erreur suivant apparaît : Erreur de serveur dans l'application '/'.
---------------------------------------------
Les autorisations requises ne peuvent pas être acquises .
Description : une exception non gérée s'est produite lors de l'exécution de la requête Web actuelle. Veuillez consulter la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.
Détails de l'exception : System.Security.Policy.PolicyException : les autorisations requises ne peuvent pas être acquises. .
Erreur source :
une exception non gérée a été générée lors de l'exécution de la requête Web actuelle. Les informations concernant l'origine et l'emplacement de l'exception peuvent être identifiées à l'aide de la trace de la pile d'exceptions ci-dessous
:
[PolicyException : les autorisations requises ne peuvent pas être acquises.]
System.Security.SecurityManager.ResolvePolicy (Preuves, PermissionSet reqdPset, PermissionSet optPset, PermissionSet denyPset, PermissionSet& refusé, Boolean checkExecutionPermission) +2738293
System.Security.SecurityManager.ResolvePoli
.51205.0, Culture=neutral, PublicKeyToken=null' ou l'une de ses dépendances. Échec de l'octroi des demandes d'autorisation minimale (exception de HRESULT : 0x80131417)]
System.Reflection.Assembly.nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) +0
System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +211
System.Reflection.Assembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +141
System.Reflection.Assembly.Load(String assemblyString) +25
System.Web.Configuration.CompilationSection.LoadAssemblyHelper (String assemblyName, Boolean starDirective) +32
Analyse du problème :
D'après mon observation, la dll générée directement par l'application asp.net peut être chargée normalement, et la dll externe directement appelée par asp.net peut également être chargée normalement, mais d'autres dll externes qui sont uniquement référencées par la dll externe ne peuvent pas être chargé. Je suppose que les autorisations étant incomplètes, les DLL générées par l'application asp.net elle-même et les DLL directement référencées peuvent obtenir des autorisations via l'héritage des autorisations, tandis que les autres DLL externes référencées uniquement par des DLL externes ne peuvent pas hériter des autorisations en raison de restrictions d'autorisation. il y a donc un problème d'autorisations insuffisantes.
Résolution de problèmes :
Grâce à des expériences sur mon ordinateur, il est supposé que les paramètres du fichier web.config racine (sur mon ordinateur, son emplacement est C:WINDOWSMicrosoft.NETFrameworkv2.0.50727CONFIG) ont été modifiés sur l'hôte virtuel.
La section de configuration des autorisations web.config par défaut est la suivante :
<emplacementallowOverride="true">
<système.web>
<Politique de sécurité>
<trustLevel name="Full" PolicyFile="internal" />
<trustLevel name="High" PolicyFile="web_hightrust.config" />
<trustLevel name="Medium" PolicyFile="web_mediumtrust.config" />
<trustLevel name="Faible" PolicyFile="web_lowtrust.config" />
<trustLevel name="Minimal" PolicyFile="web_minimaltrust.config" />
</sécuritéPolitique>
<trust level="Full" originUrl="" />
</system.web>
</emplacement>
Vraisemblablement les paramètres modifiés sur l'hôte virtuel : <location allowOverride="false">
<système.web>
<Politique de sécurité>
<trustLevel name="Full" PolicyFile="internal" />
<trustLevel name="High" PolicyFile="web_hightrust.config" />
<trustLevel name="Medium" PolicyFile="web_mediumtrust.config" />
<trustLevel name="Faible" PolicyFile="web_lowtrust.config" />
<trustLevel name="Minimal" PolicyFile="web_minimaltrust.config" />
</sécuritéPolitique>
<niveau de confiance="Élevé" originUrl="" />
</system.web>
</location> Il définit d'abord allowOverride sur false, ce qui empêche la possibilité de redéfinir les autorisations dans le fichier web.config de l'utilisateur. Ensuite, il a défini le niveau de confiance comme Élevé au lieu du niveau Complet par défaut. Après mes tests, tant que le niveau de confiance n'est pas Complet, les autres DLL externes référencées uniquement par la DLL externe ne peuvent pas être chargées. Par conséquent, je recommande au support technique de définir la sectionallowOverride sur true. De cette façon, je peux re-spécifier les autorisations dans web.config.
Exemple : <trust level="Full" originUrl="" />
Je n'ai pas étudié aps.net récemment, donc je n'ai pas soigneusement recherché les raisons sous-jacentes. Peut-être que ma compréhension est fausse. J'espère que l'expert pourra m'en expliquer les raisons sous-jacentes ou corriger mes erreurs.