Quelle est la différence insécurité un navigateur et un client Web?

Question

J'ai une page ASP.Net qui fait un certain travail d'IO de dossier. Lorsque je le demande à partir d'un navigateur Web, à savoir chrome, il réussit, mais lorsque je le demande à partir d'une instance WebClient dans mon application, il me donne une 'System.Security.SecurityException'. Y a-t-il des différences significatives entre les deux demandes? Que dois-je savoir sur la sécurité d'accès au code pour que cette page fonctionne à partir de mon client Web?

Voici les demandes violoneux premières et réponses:

Browser Demande:

GET http://192.168.1.89/QuickCutConsoleDataProvider/UpdateItemFiles.aspx HTTP/1.1 
Host: 192.168.1.89 
Proxy-Connection: keep-alive 
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-US,en;q=0.8 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 

Réponse du navigateur:

HTTP/1.1 200 OK 
Via: 1.1 PHOBOS 
Connection: Keep-Alive 
Proxy-Connection: Keep-Alive 
Content-Length: 35189 
Date: Tue, 14 Dec 2010 14:08:46 GMT 
Content-Type: application/zip 
Server: Microsoft-IIS/7.5 
Cache-Control: private 
X-AspNet-Version: 2.0.50727 
X-Powered-By: ASP.NET 

... Binary Content ... 

Web Demande client:

POST http://192.168.1.89/QuickCutConsoleDataProvider/UpdateItemFiles.aspx?Guid=e30e1826-3d96-4769-a540-acd911cccf02 HTTP/1.1 
Content-Type: multipart/form-data; boundary=---------------------8cd697dcbf75ed4 
Host: 192.168.1.89 
Content-Length: 303 
Expect: 100-continue 

-----------------------8cd697dcbf75ed4 
Content-Disposition: form-data; name="file"; filename="Catalog.xml" 
Content-Type: application/octet-stream 

<?xml version="1.0" encoding="utf-8" standalone="yes"?> 
<catalog version="1.0"> 
    <items /> 
</catalog> 
-----------------------8cd697dcbf75ed4-- 

réponse du client Web (exception):

HTTP/1.1 200 OK 
Via: 1.1 PHOBOS 
Connection: Keep-Alive 
Proxy-Connection: Keep-Alive 
Content-Length: 1244 
Date: Tue, 14 Dec 2010 14:12:34 GMT 
Content-Type: text/xml; charset=utf-8 
Server: Microsoft-IIS/7.5 
Cache-Control: private 
X-AspNet-Version: 2.0.50727 
X-Powered-By: ASP.NET 

<error type="System.Security.SecurityException"> 
    <message>Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.</message> 
    <stack-trace><![CDATA[ at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet) 
    at System.Security.CodeAccessPermission.Demand() 
    at System.IO.File.GetLastWriteTimeUtc(String path) 
    at Ionic.Zip.ZipEntry.Create(String nameInArchive, ZipEntrySource source, Object arg1, Object arg2) 
    at Ionic.Zip.ZipEntry.CreateFromFile(String filename, String nameInArchive) 
    at Ionic.Zip.ZipFile.AddFile(String fileName, String directoryPathInArchive) 
    at Ionic.Zip.ZipFile.AddFile(String fileName) 
    at MyApplication.UpdateItemFiles.GetUpdateContent(XDocument a_xManifest, Stream[] a_arrExtraContent) in C:\Software\MyApplication\Alpha\Web Interface\UpdateItemFiles.aspx.cs:line 282 
    at MyApplication.UpdateItemFiles.Page_Load(Object sender, EventArgs e) in C:\Software\MyApplication\Alpha\Web Interface\UpdateItemFiles.aspx.cs:line 31]]></stack-trace> 
    <inner-exception>null</inner-exception> 
</error> 

Answer 1

Le problème n'avait rien à voir avec l'authentification IIS. C'était la bibliothèque Zip que j'utilisais, DotNetZip. CAS n'était pas disposé à lui accorder des autorisations d'accès aux fichiers. J'ai finalement eu à proxy opérations d'E/S avec les flux de fichiers. Le seul inconvénient est que le fichier que je voulais ajouter à l'archive Zip, j'ai dû laisser un flux ouvert jusqu'à ce que l'archive soit sauvegardée. Ils étaient des flux de fichiers, donc il y avait très peu de mémoire utilisée. Quelqu'un a mentionné WCF, et cela aurait été idéal, mais le décideur a décidé que cette façon était trop coûteuse.

Answer 2

Ceci est très bien encore en cours d'exécution dans l'authentification Windows - même si vous croyez que vous avez changé. Je parie que l'usurpation d'identité est également en cours.

Vérifiez à nouveau l'authentification. Cracher un code de débogage pour consigner l'identité actuelle lors de l'opération d'E/S.