Qu'est-ce qui ne va pas avec ma demande d'adhésion à ValidateUser? (using ClientFormsAuthenticationMembershipProvider)

Question

Existe-t-il des diagnostics simples que je peux exécuter pour déterminer pourquoi l'authentification ne fonctionne pas avec le fournisseur ClientFormsAuthenticationMembershipProvider? Mon problème:

J'ai un site Web (nous l'appellerons le site Web "Authenticator") hébergé sur le serveur A qui est configuré pour utiliser le fournisseur AspNetSqlMembershipProvider pour la gestion des membres et des rôles. Les (ce que je pense est) clés web.config pertinentes pour ce site Web sont les suivants:

<membership> 
     <providers> 
      <clear /> 
      <add name="AspNetSqlMembershipProvider" 
       type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
       connectionStringName="MMMS35.API" 
       enablePasswordRetrieval="false" 
       enablePasswordReset="true" 
       requiresQuestionAndAnswer="false" 
       applicationName="Moose" 
       requiresUniqueEmail="false" 
       passwordFormat="Hashed" 
       maxInvalidPasswordAttempts="5" 
       minRequiredPasswordLength="7" 
       minRequiredNonalphanumericCharacters="0" 
       passwordAttemptWindow="1" 
       passwordStrengthRegularExpression="" /> 
     </providers> 
    </membership> 
    <profile> 
     <providers> 
      <clear /> 
      <add name="AspNetSqlProfileProvider" 
       connectionStringName="MMMS35.API" 
       applicationName="Moose" 
       type="System.Web.Profile.SqlProfileProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 
     </providers> 
    </profile> 
    <roleManager enabled="true"> 
     <providers> 
      <clear /> 
      <add name="AspNetSqlRoleProvider" 
       connectionStringName="MMMS35.API" 
       applicationName="Moose" 
       type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 
     </providers> 
    </roleManager> 

J'ai un autre site web (appelé le site Web « Test Client ») hébergé sur le serveur B sur le même réseau que B. Le client de test a une configuration de connexion fictive, qui utilise le fournisseur ClientFormsAuthenticationMembershipProvider pour demander au site Web «Authenticator» de s'authentifier. les informations d'identification fournies sur le client de test. Les sections web.config pertinentes du client de test sont les suivants:

<membership defaultProvider="ClientAuthenticationMembershipProvider"> 
     <providers> 
      <clear/> 
      <add name="ClientAuthenticationMembershipProvider" 
       type="System.Web.ClientServices.Providers.ClientFormsAuthenticationMembershipProvider, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
       serviceUri="http://slmooseapp1/mia/Authentication_JSON_AppService.axd" 
       credentialsProvider="" 
       savePasswordHashLocally="False"/> 
     </providers> 
    </membership> 
    <roleManager defaultProvider="ClientRoleProvider" enabled="true"> 
     <providers> 
      <clear/> 
      <add name="ClientRoleProvider" 
       type="System.Web.ClientServices.Providers.ClientRoleProvider, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" 
       serviceUri="http://slmooseapp1/mia/Role_JSON_AppService.axd" 
       cacheTimeout="1"/> 
     </providers> 
    </roleManager> 

Lorsque le client de test exécute cette ligne:

DirectCast(Membership.Provider, ClientServices.Providers.ClientFormsAuthenticationMembershipProvider).ValidateUser(UserName.Text, Password.Text) 

je reçois une exception:

System.UnauthorizedAccessException: Access to the path 'C:\Documents and Settings\Default User\Application Data\Microsoft Corporation\Internet Information Services\6.0.3790.3959' is denied. 

Toutefois, lorsque J'exécute le client de test sur ma boîte de développement (pas sur le serveur B) avec exactement les mêmes chemins webUnderv serviceUri (ie, mon fournisseur d'appartenance client pointe vers le même site Web d'authentification sur le serveur A), en validant un utilisateur et obtenir les rôles pour cet utilisateur fonctionne parfaitement. Si j'ouvre un navigateur sur le serveur B et que je demande une page du site Web d'authentification, l'application Web d'authentification fonctionne correctement, et je sais que je peux traiter les demandes http du serveur B vers le serveur A avec succès. Que se passe-t-il avec le ClientFormsAuthenticationMembershipProvider qui échoue lorsqu'il essaie de faire (ce que je pense être) une requête JSON du Serveur B au Serveur A?

EDIT (9/21/2009):

J'ai essayé ce scénario maintenant avec le site Web d'authentification et le client de test sur la même case (ce qui est ma machine de développement). Il échoue toujours. J'ai écrit une demande Http première et programmation a réussi à avoir une réponse positive ...

Demande:

Content-Type: application/json 
Host: slappdev 
Content-Length: 70 
Expect: 100-continue 
Connection: Keep-Alive 

{"userName":"mdh","password":"test123","createPersistentCookie":false} 

Réponse:

MicrosoftOfficeWebServer: 5.0_Pub 
Content-Length: 10 
Cache-Control: private, max-age=0 
Content-Type: application/json; charset=utf-8 
Date: Mon, 21 Sep 2009 20:10:13 GMT 
Set-Cookie: AppName=1756811D52C4619AC78...; path=/; HttpOnly 
Server: Microsoft-IIS/6.0 
X-AspNet-Version: 2.0.50727 
X-Powered-By: ASP.NET 

{"d":true} 

Donc, je suppose que quelque chose ne va pas tout en travaillant à travers les appels de framework .Net pour obtenir de ValidateUser à la requête HTTP actuelle. Des idées?

Edit (9/22/2009):

L'exception levée est exactement la même exception lancée comme lorsque ma page web client de test tente d'accéder System.Windows.Forms.Application.UserAppDataPath. L'ajout d'un attribut connectionStringName à la clé d'appartenance/providers/add qui pointe vers un nom de chaîne de connexion valide dans le fichier web.config de l'application Web client modifie l'exception!Donc, si toutes les fonctions d'appartenance utilisent le serviceUri, pourquoi quelque chose est-il tenté localement sur le client? Et, quel utilitaire dois-je exécuter pour ajouter ces nouveaux tableaux/objets dans ma base de données pour prendre en charge le fournisseur d'appartenances client?

Answer 1

Le ClientAuthenticationMembershipProvider dispose d'une fonction de cache en mode hors connexion. Dans le cas où le fournisseur d'appartenance réel ne peut pas être atteint, le fournisseur d'appartenance client peut mettre en cache les informations d'identification sur l'ordinateur client et utiliser ces informations d'identification en mode hors connexion. Ce cache hors connexion est représenté par un fichier de base de données SQL Server Compact Edition généré automatiquement et stocké dans l'emplacement System.Windows.Forms.Application.UserAppDataPath.

Selon this MSDN article, vous pouvez configurer le cache local hors ligne pour utiliser une base de données. Vous devez créer manuellement les tables de base de données comme spécifié dans l'article (dans mon édition 9/22, je n'avais pas encore créé ces tables, et il n'y a aucun utilitaire pour le faire). Je l'ai fait, mais le client voulait toujours créer la structure de dossier sur la machine locale pour le fichier SQL CE local, même s'il ne créerait jamais un tel fichier. Pour chaque machine dans mes tests EXCEPT mon poste de travail local, l'utilisateur IIS n'a pas pu créer cette structure de dossiers pour la base de données de cache local, qui a généré l'exception UnauthorizedAccessException. Je suis plutôt mécontent que A) il n'y a pas de clé de configuration pour désactiver le cache hors ligne pour l'appartenance, et B) même en dirigeant le cache hors ligne vers une base de données, le fournisseur d'appartenance client doit toujours créer un chemin de dossier vers le fichier de cache local qu'il ne crée jamais.

Answer 2

Si vous ajoutez une balise system.diagnostic dans votre fichier web.config, cela fonctionne. (j'obtenir ici seulement un fichier vide, mais pas non plus un message d'erreur.)

<system.diagnostics> 
     <sources> 
      <!-- This section defines the logging configuration for My.Application.Log --> 
      <source name="DefaultSource" switchName="DefaultSwitch"> 
       <listeners> 
        <add name="myListener"/> 
        <!-- Uncomment the below section to write to the Application Event Log --> 
        <!--<add name="EventLog"/>--> 
       </listeners> 
      </source> 
     </sources> 
     <switches> 
      <add name="DefaultSwitch" value="Information" /> 
     </switches> 
     <sharedListeners> 
      <add name="myListener" 
         type="System.Diagnostics.TextWriterTraceListener" 
         initializeData="c:\temp\MyFile.log" /> 
      <!-- Uncomment the below section and replace APPLICATION_NAME with the name of your application to write to the Application Event Log --> 
      <!--<add name="EventLog" type="System.Diagnostics.EventLogTraceListener" initializeData="APPLICATION_NAME"/> --> 
     </sharedListeners> 
    </system.diagnostics>