c# - usuario - tener un problema con la verificación de credenciales de membresía falló cuando no debería estar usándolo

membership c# ejemplo (6)

Eso es muy sospechoso que suceda justo en ese momento.

Estoy de acuerdo, pero parece que en el paso # 4 redireccionas el sitio y luego el usuario realiza la entrada de datos. Si un usuario ocasionalmente toma de 10 a 20 minutos para ingresar esa información (debido a la distracción, etc.), es mucho más probable que si se tratara de una simple condición de carrera.

Si todavía tiene los datos de todos los errores, puede mirar hacia atrás para ver si puede encontrar un patrón en los momentos en que esto sucede (o cada xx horas, consulte a continuación).

Verifique la configuración de IIS para ver cuándo se recicla el grupo de aplicaciones. ¿Se recicla alrededor de las 4am cada noche? ¿Está en un horario móvil? De forma predeterminada, IIS se recicla en un número impar de horas por algún motivo (creo que cada 28 horas).
Salga del estado de sesión InProc y entre en State Server (o SQL). InProc solo causará dolor de todas formas a largo plazo. Tenga en cuenta que cuando realice este cambio, debe asegurarse de que todos los objetos que ponga en la sesión sean serializables, de lo contrario obtendrá errores. InProc no requiere que los objetos se serialicen en sesión.

Edición: Ok, para comprobar el reciclaje de su grupo de aplicaciones:

En el Administrador de IIS, seleccione el grupo de aplicaciones apropiado y seleccione Configuración avanzada (haga clic con el botón derecho o use el menú del lado derecho).
Desplácese hasta la parte inferior, a la sección Reciclaje
El intervalo de tiempo regular restablecerá el grupo de aplicaciones cada xx minutos. El valor predeterminado es 1740 minutos, o cada 29 horas.
La configuración de tiempos específicos le permite establecer un tiempo programado para que se recicle.

En general, QUIERES reciclar el grupo de aplicaciones periódicamente (probablemente a diario).

Para responder a su segunda pregunta: si esta es la causa, no es una cuestión de tiempo de espera; es una cuestión de si el grupo de aplicaciones se recicla durante el período de tiempo entre el momento en que se redirigen y cuando se redireccionan. Cambiar su estado de sesión a algo que no sea InProc debería resolver este problema.

Dicho esto, la sesión que expira podría TAMBIÉN ser la causa de esto, por lo que configurar su tiempo de espera de sesión en un valor mayor también podría resolver esto.

Si observa más detenidamente los registros durante los periodos de tiempo en que esto sucedió, podría dar más pistas de lo que está sucediendo.

Editar # 2

Vea si puede aislar las ocurrencias del error en los registros. Si puede, vea si hay un patrón en el navegador que se está utilizando. También buscaría otros patrones para ver si algo salta.

Puede probar con varios navegadores diferentes (incluido el móvil) para ver si puede reproducir. Además, pruebe diferentes versiones de IE y diferentes configuraciones de seguridad en IE.

Como nuestro sitio web no puede aceptar tarjetas de crédito directamente, estamos enrutando al usuario, con credenciales y otras variables misc, a una ''página alojada'' en otro sitio.

Para ir más detalladamente, así es como el usuario accedería a esto en general:

Vaya a nuestro sitio e inicie sesión con un nombre de usuario y contraseña que crearon anteriormente. Esto utiliza el proveedor de membresía asp.net.
Una vez iniciada la sesión, les mostramos su cuenta y tienen un botón para hacer un pago. Una vez que hacen clic en este ...
Se les solicita una página de ''pago anticipado'' para verificar la cantidad y varios otros bits de información. Hacen click en continuar desde aquí ...
Por lo tanto, la página de pago se muestra dentro de un iframe de nuestro sitio web. Los redirigimos a la página web alojada externa con el siguiente código:
<div align = "center"> <iframe width = "100%" height = "600px" src = "@ Html.Raw (@ ViewBag.GateWayWebsite)"> </ div>
Una vez que la página de pago ha sido ingresada y el cliente hace clic en enviar, ese sitio envía una publicación a nuestro sitio web donde comenzaron y devuelve la información sobre el cargo. Tomo esta información y la guardo en nuestra base de datos y muestro un recibo.

Todo funciona bien, excepto para el # 5. Eso funciona la mayor parte del tiempo, pero aproximadamente 1 de cada 10 vuelve con este mensaje:

Event code: 4006 Event message: Membership credential verification failed. Event time: 12/16/2013 4:32:22 AM Event time (UTC): 12/16/2013 12:32:22 PM Event ID: 42c509f2a25d46f0af17e72a52dfbbe5 Event sequence: 38 Event occurrence: 1 Event detail code: 0 Application information: Application domain: /LM/W3SVC/3/ROOT/SuburbanCustPortal-1-130316693110399868 Trust level: Full Application Virtual Path: /SuburbanCustPortal Application Path: C:/inetpub/wp/SuburbanCustPortal/ Machine name: WIN-OB929P97YAR Process information: Process ID: 3620 Process name: w3wp.exe Account name: NT AUTHORITY/NETWORK SERVICE Request information: Request URL: https://myurl:443/SuburbanCustPortal/Account/Logon2 Request path: /SuburbanCustPortal/Account/Logon2 User host address: xx.xx.xx.xx User: Is authenticated: False Authentication Type: Thread account name: NT AUTHORITY/NETWORK SERVICE Name to authenticate: testuser

No puedo pasar en el puñado de casos de prueba que he ejecutado, lo que lo hace mucho más frustrante.

Este es mi web.config:

<?xml version="1.0"?>  <configuration> <appSettings> <add key="webpages:Version" value="1.0.0.0"/> <add key="ClientValidationEnabled" value="true"/> <add key="UnobtrusiveJavaScriptEnabled" value="true"/> <add key="suburbanServiceUrl" value=""/> </appSettings> <system.web> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="60" sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI" cookieless="false" timeout="60" /> <customErrors mode="Off"/> <compilation debug="true" targetFramework="4.0"> <assemblies> <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> </assemblies> </compilation> <authentication mode="Forms">  <forms loginUrl="~/Account/LogOn" timeout="60"/> </authentication> <membership> <providers> <clear/> <add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="true" maxInvalidPasswordAttempts="30" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="webportal"/> </providers> </membership> <profile> <providers> <clear/> <add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider" connectionStringName="ApplicationServices" applicationName="/"/> </providers> </profile> <roleManager enabled="true"> <providers> <clear/> <add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider" connectionStringName="ApplicationServices" applicationName="/"/> <add name="AspNetWindowsTokenRoleProvider" type="System.Web.Security.WindowsTokenRoleProvider" applicationName="/"/> </providers> </roleManager> <pages enableSessionState="true"> <namespaces> <add namespace="System.Web.Helpers"/> <add namespace="System.Web.Mvc"/> <add namespace="System.Web.Mvc.Ajax"/> <add namespace="System.Web.Mvc.Html"/> <add namespace="System.Web.Routing"/> <add namespace="System.Web.WebPages"/> </namespaces> </pages> </system.web> <system.webServer> <validation validateIntegratedModeConfiguration="false"/> <modules runAllManagedModulesForAllRequests="true"> <remove name="Session"/> <add name="Session" type="System.Web.SessionState.SessionStateModule"/> </modules> <httpProtocol> </httpProtocol> <staticContent> <clientCache cacheControlCustom="public" cacheControlMaxAge="00:00:01" cacheControlMode="UseMaxAge" /> </staticContent> </system.webServer> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35"/> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0"/> </dependentAssembly> </assemblyBinding> </runtime> <system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_ISuburbanService" maxReceivedMessageSize="128072" /> </basicHttpBinding> </bindings> <client> <endpoint address="http://localhost:2181/ISuburbanService.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISuburbanService" contract="SuburbanService.ISuburbanService" name="BasicHttpBinding_ISuburbanService" /> </client>   </system.serviceModel> </configuration>

Y el método que capta el post:

[NoCache] [HttpPost] public ActionResult Receipt(string id) { var sb = new StringBuilder(); try { sb.AppendLine("ActionResult Reciept(string account)"); var count = 0; var postVals = new Dictionary<string, string>(); foreach (var key in Request.Form.AllKeys) { sb.AppendLine("count: " + count); sb.AppendLine(string.Format("key: {0} Value: {1}", key, Request.Form[key])); postVals.Add(key, Request.Form[key]); sb.AppendLine("finished count: " + count); count++; } sb.AppendLine("finished processing ALLKeys"); var paymentReq = createPaymentRequest(postVals); sb.AppendLine("finished processing ''var paymentReq = createPaymentRequest(postVals)'' "); var receipt = _client.RecordPaymentWithRequest(paymentReq); var retval = PartialView(receipt.Duplicate ? "Duplicate Receipt" : "Receipt", receipt); sb.AppendLine(string.Format("retval: {0}", retval)); return retval; } catch (Exception ex) { sb.AppendLine(string.Format("Receipt error: {0}", ex.Message)); Logging.LogException("Receipt error!", ex, _asName); throw; } finally { Logging.LogInfo(sb.ToString(), _asName); } }

Como puede ver arriba, no tengo [Authorize] en él, por lo que no debería ser necesario que el proveedor de membresía verifique el acceso. El nivel de clase tampoco.

¿Alguien tiene alguna sugerencia de lo que podría estar pasando?

ACTUALIZAR

2013-12-16 04:22:14 xxx.xxx.xxx.xxx GET /SuburbanCustPortal/Scripts/Views/logon.js - 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Linux;+Android+4.2.2;+en-us;+SAMSUNG+SGH-M919+Build/JDQ39)+AppleWebKit/535.19+(KHTML,+like+Gecko)+Version/1.0+Chrome/18.0.1025.308+Mobile+Safari/535.19 304 0 0 109 2013-12-16 04:22:14 xxx.xxx.xxx.xxx GET /SuburbanCustPortal/Content/images/mod/modavoca.png - 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Linux;+Android+4.2.2;+en-us;+SAMSUNG+SGH-M919+Build/JDQ39)+AppleWebKit/535.19+(KHTML,+like+Gecko)+Version/1.0+Chrome/18.0.1025.308+Mobile+Safari/535.19 304 0 0 93 2013-12-16 04:22:15 xxx.xxx.xxx.xxx GET /Content/favicon.ico - 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Linux;+Android+4.2.2;+en-us;+SAMSUNG+SGH-M919+Build/JDQ39)+AppleWebKit/535.19+(KHTML,+like+Gecko)+Version/1.0+Chrome/18.0.1025.308+Mobile+Safari/535.19 404 0 2 250 2013-12-16 04:22:15 xxx.xxx.xxx.xxx GET /apple-touch-icon-precomposed.png - 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Linux;+Android+4.2.2;+en-us;+SAMSUNG+SGH-M919+Build/JDQ39)+AppleWebKit/535.19+(KHTML,+like+Gecko)+Version/1.0+Chrome/18.0.1025.308+Mobile+Safari/535.19 404 0 2 250 2013-12-16 04:22:15 xxx.xxx.xxx.xxx GET /apple-touch-icon.png - 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(Linux;+Android+4.2.2;+en-us;+SAMSUNG+SGH-M919+Build/JDQ39)+AppleWebKit/535.19+(KHTML,+like+Gecko)+Version/1.0+Chrome/18.0.1025.308+Mobile+Safari/535.19 404 0 2 78 #Software: Microsoft Internet Information Services 7.0 #Version: 1.0 #Date: 2013-12-16 04:39:52 #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken 2013-12-16 04:39:52 xxx.xxx.xxx.xxx GET / - 443 - xxx.xxx.xxx.xxx - 200 0 0 171 2013-12-16 04:50:12 xxx.xxx.xxx.xxx POST /SuburbanHUB/ISuburbanService.svc - 443 suburbansoftware xxx.xxx.xxx.xxx - 200 0 0 875 2013-12-16 04:50:12 xxx.xxx.xxx.xxx POST /SuburbanHUB/ISuburbanService.svc - 443 suburbansoftware xxx.xxx.xxx.xxx - 200 0 0 187 2013-12-16 04:50:12 xxx.xxx.xxx.xxx GET /SuburbanCustPortal/Account/Verify id=dde4bbfb-0d2e-4706-a604-36eea3fdcae3&verifyid=c0b4fdb5-9bb3-4d2b-b724-df42e6ea2a59 443 - xxx.xxx.xxx.xxx Mozilla/5.0+(iPhone;+CPU+iPhone+OS+7_0_3+like+Mac+OS+X)+AppleWebKit/537.51.1+(KHTML,+like+Gecko)+Version/7.0+Mobile/11B511+Safari/9537.53 200 0 0 1328 2013-12-16 04:50:12 xxx.xxx.xxx.xxx GET /SuburbanCustPortal/Content/reset.css - 443 - xxx.xxx.xxx.xxxMozilla/5.0+(iPhone;+CPU+iPhone+OS+7_0_3+like+Mac+OS+X)+AppleWebKit/537.51.1+(KHTML,+like+Gecko)+Version/7.0+Mobile/11B511+Safari/9537.53 200 0 0 453

Hay un lapso en el registro de 04:22:15 a 04:39:52

¿Esto es normal?

EDITAR

Aclaré los pasos anteriores para aquellos que preguntaron.

Consulte el siguiente artículo de ScottGu http://weblogs.asp.net/scottgu/archive/2006/04/22/Always-set-the-_2200_applicationName_2200_-property-when-configuring-ASP.NET-2.0-Membership-and-other-Providers.aspx .

Además, asegúrese de que el valor "Nombre de la aplicación" en la tabla de base de datos "aspnet_Applications" y el valor de la propiedad "nombre de la aplicación" para todos los proveedores en web.config (proveedor de membresía, proveedor de roles, proveedor de perfiles, etc.) deben volver a tener el mismo valor cuidadosamente. .

Espero que esto solucione tu problema!

Después de mirar alrededor de la web, aquí están las soluciones que he encontrado donde las personas han tenido su error 4006 y finalmente han solucionado el problema.

campo applicationName establecido en "/" . - Esta es la conversación más común sobre su problema. Pero, el campo applicationName se ve bien, así que definitivamente no lo es.
Problema con ActiveDirectoryMembershipProvider - Link . Parece que es poco probable que sea tu problema porque estás usando el SqlMembershipProvider .
El usuario de Internet no tiene permisos en los archivos .mdf y .ldf - Link . Las referencias a este problema que vi fueron con personas que usan SQLExpress porque se ejecuta bajo la cuenta de usuario ASP.NET y necesita acceso de lectura / escritura. Nuevamente, parece poco probable que esto sea su problema porque solo lo tiene de forma intermitente. Pero está relacionado con el error 4006, por lo que vale la pena ver los permisos de verificación del usuario.
Contraseñas de usuario duplicadas : no guardé un enlace, pero si no tiene restricciones únicas tanto en el nombre de usuario como en la contraseña en la base de datos, puede devolver la respuesta 4006. Por lo tanto, hasta ahora esto me parece más probable porque explicaría el comportamiento intermitente y porque las personas con frecuencia hacen doble clic cuando usan Internet. Me gustaría doble y triple revisar sus limitaciones.

Estaré feliz de ver qué más puedo encontrar, pero descartar las dos últimas parece una buena idea. Además, lo que parece más extraño acerca de la brecha en sus registros es el hecho de que los datos de EventLog muestran que el error está ocurriendo casi en medio de la brecha de IIS. Luego, después de que se reanude, hay otra brecha de registro. Parece que podría ser dos usuarios completamente diferentes. Tal vez no, solo tirar eso por ahí. Házmelo saber. Buena suerte.

Ha pasado un tiempo desde que tuve problemas como este (pero lo hice para pss hace más de 7 años).

Todo lo que @PhilSandler recomendó es bueno. Sin embargo, tengo la sensación de que la causa principal no es el reciclaje de AppPool o el tiempo de espera de la sesión. Si te desesperas, puedes probar el estado de sesión fuera de proceso .

Estoy pensando que si es aproximadamente 1 de cada 10 usuarios y aparece intermitente (ya que no se puede reproducir), entonces probablemente será una configuración específica del navegador. Supongo que los usuarios que tienen el problema tienen las cookies deshabilitadas en sus navegadores (los usuarios de FF y Chrome están más conectados que los usuarios normales de IE).

Esta hipótesis coincidiría ligeramente con la teoría de @SilverlightFox:

El conjunto de marcos que evita las cookies de terceros.

<authentication mode="Forms">

Estoy pensando que los formularios de autenticación no pueden almacenar los datos de la sesión en el lado del cliente. Las entradas fallidas en el registro de eventos de verificación de credenciales de membresía pueden ser causadas debido a las cookies deshabilitadas.

Desactive las cookies en FF o Chrome y pruebe mi hipótesis. Los dedos cruzados esto te permite reproducirlo.

Las pocas cosas que encontré en tu web.config son -

Tienes múltiples applicationName . Normalmente, IsUserInRole y GetRolesForUser deberían fallar si applicationName no es el mismo.
Además, desea establecer el proveedor predeterminado para cada proveedor, especialmente si tiene más de un proveedor como roleManager - <roleManager ... defaultProvider="DefaultRoleProvider">

Web.config actual

<membership> <providers> <clear/> <add ... applicationName="webportal"/> </providers> </membership> <profile> <providers> <clear/> <add ... applicationName="/"/> </providers> </profile> <roleManager enabled="true"> <providers> <clear/> <add ... applicationName="/"/> <add ... applicationName="/"/> </providers> </roleManager>

Eche un vistazo a web.config del blog ASP.NET Universal Providers de Scott Hanselman.

<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="60" sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI" cookieless="false" timeout="60" />

No necesita stateConnectionString , stateNetworkTimeout y sqlConnectionString para InProc . Más información here .

Me doy cuenta de que el src no está configurado correctamente en el IFrame.

<div align="center"> <iframe width="100%" height="600px" src="@Html.Raw(@ViewBag.GateWayWebsite)"></iframe></div>

GateWayWebsite debe estar correctamente codificado en HTML en caso de que contenga caracteres especiales que sean relevantes pero que no se pasen correctamente:

<div align="center"> <iframe width="100%" height="600px" src="@ViewBag.GateWayWebsite"></iframe></div>

Otra idea es que podría ser que el conjunto de marcos que está impidiendo las cookies de terceros, ya sea la configuración del navegador o el encabezado de la política de privacidad P3P . Intente abrir el enlace fuera de IFrame (es decir, la barra de direcciones cambia al sitio externo), solo como una prueba para ver si esto resuelve sus problemas.

Edit: no debería haber editado mi respuesta, ya que ahora has revertido tu voto a favor. Mi respuesta es técnicamente correcta, aunque podría no ser la respuesta que solucione su problema actual, estoy en lo cierto en que la salida de la URL es incorrecta ya que no está codificado en HTML. Creo que es mejor arreglar todo, ya que esto reduce las posibilidades de que aparezcan errores molestos en el futuro que son difíciles de depurar.