Mensajes de error almacenados en SESSION

Question

¿Es una buena práctica almacenar los mensajes de error en SESSION? Por ejemplo, después de una redirección. Pasar a través de la URL no es una solución para mí ... Me pregunto si es una buena solución ... porque ...

¿Una concientización del usuario podría causar un problema? (Una publicación que toma mucho tiempo, mientras que el contenido de ajax se obtiene de otra pestaña) que puede estropear la sesión. O eso es imposible de pasar?

¡Si el usuario hace una solicitud y falla por alguna razón para mostrar la página, entonces el mensaje puede aparecer en una página irrelevante!

Entonces? ¿Alguna alternativa?
Por ejemplo, al utilizar la POST/redirigidos/get patrón

Answer 1

Al almacenar mensajes de error en la sesión, debe tener cuidado de que dos solicitudes no sobrescriban el mensaje de los demás, antes de que se muestre. Y debe tener cuidado de que una página que debe mostrar un mensaje solo muestre su propio mensaje.

Debería mostrar los errores, cuando se producen y no redirigir antes. Además, no hay razón para redirigir en tal situación.

Answer 2

¿Es una buena práctica para almacenar mensajes de error en la sesión? Por ejemplo, después de una redirección.

No en general. Los datos de sesión deben ser datos que importan durante un período significativo; los errores generalmente son el resultado de una única solicitud y los detalles no necesitan persistir.

Almacenar ese tipo de datos en una sesión es solo una invitación a las condiciones de carrera.

Answer 3

No es raro almacenar mensajes de error en sesión, especialmente en los casos en que puede haber múltiples redireccionamientos. Zend framework tiene algo así como flash messenger que hace eso.

Todo lo que está en sesión permanecerá en sesión hasta que lo destruya o hasta que la sesión se agote. La mejor práctica es almacenar los mensajes de error en la sesión, luego, cuando la página se carga donde se debe mostrar el mensaje de error, el código obtendrá los mensajes de la sesión y los mostrará si existen. Después de que se muestren los mensajes de error, deberá eliminarlos de la sesión, de lo contrario, cada vez que el usuario vaya a esta página, aparecerán los mismos mensajes de error una y otra vez.

El mejor enfoque es mostrar y eliminar.

Creo que no deberías tener ningún problema nunca si usas este enfoque. La razón es que si se envía un formulario incorrecto, siempre tendrá errores y siempre tratará de almacenar esos mensajes de error en sesión y mostrarlos en consecuencia, no importa cuántas veces se hayan agregado o eliminado en la sesión. Espero que todo esto tenga sentido.

También cuando almacena mensajes de error de sesión, debe almacenarlos inteligentemente para que el servidor sepa que estos mensajes de error están almacenados, y de qué forma.

Answer 4

¡Enfóquese en el usuario! Todos sus esfuerzos de desarrollo quieren brindar el mejor UX posible.

La primera pregunta es, ¿por qué necesita mensajes?

• En caso de una solicitud exitosa , desea que el usuario sepa que su solicitud se ha ejecutado correctamente.
• En caso de una solicitud errónea, se puede distinguir: si la solicitud puede ser alterado por el usuario se convierta en una solicitud exitosa, a continuación, mostrar un útil mensaje de error (por ejemplo envío de un formulario simple). Si el usuario no puede modificar la solicitud, sea lo más informativo posible por qué falló la solicitud (por ejemplo, "No se pudo ejecutar porque el servicio XY no está disponible. Póngase en contacto con el servicio técnico, etc.").

Fácil: Solicitud errónea de que puede alterarse:

En caso de una solicitud errónea donde el usuario puede alterar la solicitud, no lo guarda en la sesión y directamente representar la página donde el el usuario puede corregir su solicitud.

Difícil: solicitud exitosa o solicitud errónea de que no puede ser alterado:

Aquí generalmente lo desea, puede que el usuario no sea capaz de ejecutar la misma petición exacta de nuevo después de golpear F5 o tomar acciones similares, por lo tanto, redirige al usuario. En este caso, yo personalmente estoy a favor de la solución con un componente de mensajes flash (vea Symfony Docs o Zend Docs para un ejemplo). En general, esta técnica no conduce a condiciones de carrera si sus aplicaciones cumplen con estas suposiciones:

• Sus solicitudes HTTP disparadas desde el navegador se ejecutan rápidamente. Un usuario no tiene una posibilidad real de disparar una segunda solicitud mientras tanto.
• Las llamadas AJAX no influyen en los mensajes flash, o, si devuelve datos estructurados (XML, JSON), puede incluir una sección especial para mensajes flash, que luego están siendo renderizados por Javascript.

Ahora, para minimizar las tasas de error que puede hacer lo siguiente:

• tienda de la marca de tiempo cuando agregó el mensaje flash. No mostrar mensajes antiguos (por ejemplo,> 1 minuto). Un usuario móvil puede perder la conexión y luego volver a intentarlo. ¿En qué estado espera que esté la aplicación?
• No permita que las solicitudes HTTP entre su usuario y su servidor tarden mucho. Si necesita realizar cálculos largos, intente descargar cosas a un trabajador en segundo plano y muestre el estado del procesamiento al usuario.

Resumiendo: Si usted tiene buenas prácticas generales relativas a la comunicación HTTP en su lugar, el usuario es poco probable capaz de desordenar flash. Sopese los pros y los contras y concéntrese en el usuario, no en la complejidad de su implementación, ya que existen métodos para lidiar con eso.

Answer 5

En términos generales:

tratar de poner tanto en el lado del cliente (Javascript y las galletas) y tratar de almacenar lo menos posible en el lado del servidor.

Esto incluye la variable SESSION, que en el mejor de los casos solo debe contener el ID de usuario.

Si el mensaje está después de la redirección, puede agregar una variable de solicitud que pueda indexar el mensaje y mostrarlo de esa manera.

Answer 6

¿por qué no les asigna una identificación específica como error_id = 2 y la envía a través de la url? o esto tampoco es posible en su caso? también podría enviar un ID de error a través de la sesión ...

Answer 7

En lugar de almacenar en una sesión, podría pasar un código de error en la URL que luego utilizaría para buscar el error. Tengo usuario escueto clases de excepción para esta cosa un poco:

class MyException extends Exception 
{ 
    const USER_NOT_FOUND = 'The requested user was not found'; 
    // ... 
} 

Entonces su URL redirigida sería algo así como /controller/action/error/USER_NOT_FOUND y que haría uso que para buscar el mensaje:

echo constant('MyException::' . $error); 

Usted no es necesario utilizar una clase Exception para esto, pero le permite mantener las cosas realmente ordenada

if ($errorState) { 
    throw new MyException(
     MyException::USER_NOT_FOUND 
    ); 
}