asp.net-mvc - net - razor if

Escribir en una sesión de solo lectura en MVC 3+

Question

Me he encontrado con un curioso comportamiento de sesiones ASP. Puede obligar a un controlador a estar fuera de la sesión del usuario; deseo poder hacer esto para que se puedan ejecutar varias solicitudes al mismo tiempo y usar una sesión hace que se ejecuten de forma consecutiva.

Deshabilitar el estado de la sesión funciona como se espera:

[SessionState(SessionStateBehavior.Disabled)]
public class SampleController : Controller
{
    public ActionResult Test() 
    {
        // Access to the session should be denied
        object test = Session["test"];
        return Content(test);
    }
}

Ir a ~ / Sample / Test lanzará una System.Web.HttpException , como se esperaba. Sin embargo, las sesiones de solo lectura parecen comportarse de forma extraña:

[SessionState(SessionStateBehavior.ReadOnly)]
public class SampleController : Controller
{
    public ActionResult Test() 
    {
        // Read from the session should be fine
        object test = Session["test"];
        return Content(test);
    }

    public ActionResult SetTest(string value) 
    {
        // Write to the session should fail 
        Session["test"] = value;

        // Read it back from the session
        object test = Session["test"];
        return Content(test);
    }
}

Así que ahora espero que ~ / Sample / Test funcione, y lo hace. Lo extraño es que el conjunto también: voy a ~ / Sample / SetTest? Value = foo y no arroja una excepción, de hecho devuelve "foo". Si llamo a ~ / Sample / SetTest? Value = bar y luego ~ / Sample / Test , obtengo "bar", lo que indica que la sesión se ha escrito en.

Entonces, en una SessionStateBehavior.ReadOnly , SessionStateBehavior.ReadOnly con éxito en la sesión y leí mi valor nuevamente.

Creo que esto podría deberse a una de estas tres cosas:

• En MVC 3 [SessionState(SessionStateBehavior.ReadOnly)] está roto / ignorado.
• El [SessionState] se [SessionState] cuando la sesión se escribe y se puede escribir.
• SessionStateBehavior.ReadOnly realmente indica algún tipo de acceso sucio / optimista.

¿Alguien puede confirmar?

Sospecho que el último es verdadero, basado en la documentación del proveedor de sesión personalizado ; si es así, ¿cómo funciona la implementación? ¿La escritura en una sesión de "solo lectura" arriesga errores de concurrencia (es decir, la última escritura gana) o corre el riesgo de sesiones corruptas y excepciones de ruptura?

Actualizar

Parece que esto es por diseño (de los documentos de Microsoft ):

Tenga en cuenta que incluso si el atributo EnableSessionState está marcado como ReadOnly, es posible que otras páginas ASP.NET en la misma aplicación puedan escribir en el almacén de sesión, por lo que una solicitud de datos de sesión de solo lectura de la tienda podría terminar esperando bloquearse. datos para ser liberados

Parece que la segunda opción anterior es lo que realmente hace: la sesión está bloqueada y el modo ha cambiado a escriturable.

Answer 1

~ / Sample / SetTest? Value = foo

Sí, no arrojará ningún error, pero tampoco persistió en la sesión al final de la solicitud. Por diseño, cualquier cosa que escriba en la sesión se actualiza (solo si la sesión es grabable) al final del ciclo de vida de la solicitud.

En mi prueba ~ / Sample / Test no devuelve nada.

Creo que deberían haber fallado rápido aquí cuando la sesión es de solo lectura.

Por cierto, tu muestra debe ser reescrita

string test = (string)this.Session["test"];