Tenemos una aplicación php escrita en zend framework y nos preguntamos cuál sería la mejor manera si quisiéramos mantener a nuestros usuarios conectados durante más de un día, p. una semana o incluso máspermanezca conectado en la aplicación php durante +1 semana
¿Necesitamos sesiones para eso? (¿usa espacio de tabla y memoria?) o ¿es mejor trabajar con cookies? (¿seguridad?)
HTTP es sin estado, lo que significa que el servidor web olvidará quién es usted después de atender su solicitud. Las sesiones están a la vuelta de esto. Al utilizar Sesiones, el navegador y el servidor intercambiarán un identificador en cada solicitud que permite al servidor web conectar datos previamente almacenados a este solicitante en particular.
La ID es generalmente almacenada en Cookie. Configure su Cookie de sesión para que caduque en una semana y estará listo para mantener a sus usuarios conectados durante una semana.
Ver
¿Estás diciendo que deberíamos mantener sesiones por una semana? ¿no sería eso utilizar datos/memoria de la tabla de sesión? ¿O es algo que no es realmente un gran problema, incluso con muchos usuarios? – Jorre
@Jorre que depende de lo que arroje al almacenamiento de la sesión y de qué * muchos * usuarios y qué capacidad de hardware tiene el sistema. Tarde o temprano, cualquier sistema alcanzará su capacidad. – Gordon
+1 para los enlaces a estos excelentes artículos :) – coldfix
En sentido estricto no es necesario sesiones. Está confundiendo dos cosas:
Así que, básicamente, las cookies se utilizan para dos propósitos - para almacenar una corta vida (minites u horas) y el ID de sesión para almacenar credenciales de usuario para un par de días/semanas/meses.
No estoy de acuerdo con el segundo punto. Nunca use credenciales en una Cookie. Esto es inseguro Además, no hay ninguna razón por la cual la sesión o su cookie debe ser de corta duración. La cookie de sesión que se elimina cuando el navegador está cerrado es solo la configuración predeterminada. Esto puede cambiarse a cualquier cosa que desee. – Gordon
@Gordon Solo es inseguro si lo haces si es inseguro. Puede marcar la cookie como segura y luego solo se enviará a través de https. – Artefacto
Eso solo usaría HTTPS del cliente al servidor. Además, no veo por qué debería usar una segunda cookie cuando esto se puede manejar fácilmente solo con la Cookie de sesión. Justo en la vida. – Gordon
"Remember me" siempre es un agujero en una seguridad, sea lo que sea que uses, cookie o sesión, alguien puede robar (teóricamente) una cookie y así ingresar una cuenta sin contraseña. Hay formas de aumentar la seguridad, permitiendo el retiro solo bajo la misma IP. Las cookies son menos seguras, pero AFAIK depende de la forma en que implemente la autenticación. Por ejemplo, al mantener el hash de contraseñas en las cookies casi le das al intruso una contraseña real (que es un no-no, puede usarse en otras aplicaciones web) ya que hay diccionarios para obtener contraseñas simples del hash. Salting hash no ayuda mucho.
En general, la sesión es la manera más simple y más que suficiente. Use tablas si usa más de un servidor web para una aplicación, de lo contrario, las sesiones en el disco estarán bien.
Aún usa cookies para implementar sesiones, si alguien intercepta la cookie puede secuestrar la sesión. Entonces, realmente no tiene mucho sentido presentar una dicotomía sesión vs. cookies. La sesión es un concepto diferente y más abstracto y las cookies son una pieza común en la implementación de dicho concepto. – Artefacto
La sesión usa cookies, eso está escrito en mi primera oración. Sin embargo, si se roba una cookie, el servidor aún puede comparar la IP del usuario y rechazar el ingreso automático. Eso también se menciona;) –
¿Qué estás usando en este momento? –