ViewStateUserKey + alojamiento compartido + error de validación de ViewStateMac

Entonces, la pregunta es simple, aunque estoy empezando a tener dudas sobre si esto será respondido ...

Tengo un sitio web en el que quería asegurar mi estado de vista con el ViewStateUserKey recomendado.

En mi página base (heredada de la página, obviamente) tengo este código:

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);

        if (User.Identity.IsAuthenticated)
            base.ViewStateUserKey = Session.SessionID;
    }

Funciona bien en localhost, sin embargo, cuando lo subo a un alojamiento (un alojamiento compartido proporcionado por uno de nuestros proveedores locales), da el error tradicional de "Validación de error de Viewstate MAC" después de la autenticación. Si comento este código, funciona perfectamente, así que estoy 1000% seguro de que esta es la causa.

¿Cuál es el mejor enfoque para realizar la seguridad de viewstate en el alojamiento compartido? Ya he configurado ViewStateMac = "Habilitado" también. ¿Es suficiente o cuál es la solución recomendada?

Respuestas a la pregunta(1)

Solución de preguntas

entonces me parece que tiene algunos problemas con la sesión, y el ID de sesión cambia / caduca rápidamente en su servidor, más rápido que la autenticación.

Y por esa razón, desde el momento en que el usuario ve la página, hasta la publicación, la sesión ha caducado o se modifica antes del cambio de autenticación, por lo que el sessionID es diferente y recibe este error.

Otro piensa que puedes mirar es que has configurado elmachineKey en web.config.

Actualizar

Compara tu código con el Scott que has hecho diferente. Scott usa el nombre de usuario, que no es un cambio en absoluto, y usted usa el sessionid, que puede cambiar como yo digo.

Para mí, ether utiliza lo que Scott sugiere, el nombre de usuario, eter otro valor que no cambia también, como la cookie del usuario, por ejemplo, que no es tan fácil cambiar.

Así que de Scotthttp://www.hanselman.com/blog/ViewStateUserKeyMakesViewStateMoreTamperresistant.aspx

void Page_Init (Object sender, EventArgs e)
{ 
   if (User.Identity.IsAuthenticated)
      ViewStateUserKey = User.Identity.Name;
}

Y esta es la razón por la que Scott comprueba si el usuario está autenticado, porque obtiene su nombre. Si va con sessionid, o la cookie del usuario, no necesita verificar si está autenticado.

Ahora, si usa la cookie para establecerlos en viewstateuserkey, para todos los usuarios, entonces el que no permita la cookie, e intente hacer cualquier publicación, obtendrá un error. Así que piensa una solución así para manejarlos.

https://stackoverflow.com/a/2551810/159270

 walther02 jun. 2012 15:45
Hmm, ok, tienes razón, eso funciona. ¿Cuál sería la mejor manera de habilitar esto para todos los usuarios? ¿Qué valor debo asignar a ViewStateUserKey para estar seguro? Por favor, actualice su respuesta con eso y lo aceptaré. Gracias por tu ayuda.
 Aristos02 jun. 2012 15:18
@walther Scott, usa el nombre de usuario! ¡Esto no es cambio! Prueba el código de Scott tal como es.
 Aristos02 jun. 2012 15:53
@walther Lo he actualizado, sin embargo, siempre que sugiero seguir con lo que hace Scott, es lo más sencillo y seguro para evitar errores.
 Aristos02 jun. 2012 15:12
@walther crea un registro de su sessionid para ver si se trata de un cambio.
 walther02 jun. 2012 15:08
Eso es exactamente lo que pensé, que mi ID de sesión ha cambiado. Sin embargo, después de algunas investigaciones (verificadas en las herramientas web de Chrome), parece que este no es el caso. Machinkey en mi web.config es generado por este sitioaspnetresources.com/tools/machineKey y por sí mismo (sin ViewStateUserKey) funciona sin problemas.
 walther02 jun. 2012 15:17
Le daré una oportunidad al registro de la sesión, veremos ... Volveré a publicar después de algunas investigaciones más.
 Aristos02 jun. 2012 15:11
@walther el sessionid está conectado con la cookie del usuario, pero está cambiado y caducado. ¿Por qué no configura directamente la cookie del usuario? Y segundo, por qué marca IsAuthenticated o no ... no hay razón para tener seguridad solo para usuarios autenticados. (Al menos eso hago en mi código, uso la cookie para todos los usuarios)
 walther02 jun. 2012 15:16
Bueno, Scott Hanselman tiene esta pieza de código en su sitio web, así que pensé que sería bueno. Originalmente lo tenía sin la verificación de usuario autenticado, pero tampoco ayudé.hanselman.com/blog/…

Su respuesta a la pregunta