que - sesiones en php

PHP: $_SESSION-¿Cuáles son los pros y los contras de almacenar datos usados temporalmente en la variable $_SESSION

Question

Una cosa que he empezado a hacer últimamente es recuperar algunos datos al comienzo de una tarea y almacenarlos en $ _SESSION [''myDataForTheTask''] .

Ahora parece muy conveniente hacerlo, pero no sé nada sobre el rendimiento, los riesgos de seguridad o similares, usando este enfoque. ¿Es algo que regularmente hacen los programadores con más experiencia o es más una cosa de aficionados que hacer?

Por ejemplo:

if (!isset($_SESSION[''dataentry'']))
{
$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=" . mysql_real_escape_string($_GET[''wave_id'']);
$result_taskinfo = $db->query($query_taskinfo);
$row_taskinfo = $result_taskinfo->fetch_row();
$dataentry = array("pcode" => $row_taskinfo[0], "modules" => $row_taskinfo[1], "data_id" => 0, "wavenum" => $row_taskinfo[2], "prequest" => FALSE, "highlight" => array());
$_SESSION[''dataentry''] = $dataentry;
}

Answer 1

$ _SESSION elementos se almacenan en la sesión, que, de forma predeterminada, se mantiene en el disco. No es necesario hacer su propia matriz y rellenarla en una entrada de matriz de ''entrada de datos'' como lo hizo. Solo puede usar $ _SESSION [''pcode''], $ _SESSION [''modules''], etc.

Como dije, la sesión se almacena en el disco y un puntero a la sesión se almacena en una cookie. Por lo tanto, el usuario no puede obtener fácilmente los datos de la sesión.

Answer 2

$ _SESSION es muy útil en seguridad, ya que es una forma del lado del servidor para almacenar información mientras un usuario está activo en sus páginas, por lo tanto, es difícil de hackear a menos que su archivo php o servidor real tenga vulnerabilidades que se explotan. Una muy buena implementación es almacenar una variable para confirmar que el usuario ha iniciado sesión, y solo permite que se tomen acciones si se confirma la sesión iniciada.

Answer 3

Algunas otras desventajas de usar sesiones:

1. $_SESSION datos de $_SESSION caducarán después de la sesión.gc_maxlifundos de inactividad por $_SESSION vez.
2. Tendrá que recordar llamar a session_start() para cada script que usará los datos de la sesión.
3. Escalar el sitio web mediante el equilibrio de carga en varios servidores podría ser un problema porque el usuario deberá dirigirse al mismo servidor cada vez. Resuelve esto con "Sesiones adhesivas".

Answer 4

El mecanismo $ _SESSION está usando cookies.

En el caso de Firefox (y tal vez el nuevo IE, no me controlé) eso significa que la sesión se comparte entre las pestañas abiertas . Eso no es algo que esperas por defecto. Y significa que la sesión ya no es "algo específico para una sola ventana / usuario".

Por ejemplo, si ha abierto dos pestañas para acceder a su sitio, luego de haber iniciado sesión como raíz usando la primera pestaña, obtendrá privilegios de administrador en la otra.

Eso es realmente inconveniente, especialmente si codifica el cliente de correo electrónico o alguna otra cosa (como e-shop). En este caso, deberá administrar las sesiones manualmente o introducir una clave regenerada constantemente en la URL o hacer otra cosa.

Answer 5

Es posible que desee considerar qué tan REST-ful es esto?

es decir, ver el párrafo "Comunicar sin estado" en " Una breve introducción al REST " ...

"REST exige que el estado se convierta en estado de recursos o se mantenga en el cliente. En otras palabras, un servidor no debería tener que retener algún tipo de estado de comunicación para ninguno de los clientes con los que se comunica más allá de una sola solicitud".

(o cualquiera de los otros enlaces en wikipedia para REST )

Entonces, en su caso, el ''wave_id'' es un Recurso razonable para GET, pero ¿realmente desea almacenarlo en la SESIÓN? Seguramente memcached es su solución para almacenar en caché el objeto Resource?

Answer 6

Esto es algo bastante común de hacer, y la sesión generalmente será más rápida que las visitas continuas a la base de datos. También son razonablemente seguros, ya que los desarrolladores de PHP han trabajado arduamente para evitar el secuestro de sesiones.

El único problema es que debe recordar reconstruir la entrada de sesión cuando algo cambia. Y, si un usuario que no sea el dueño de la sesión cambia algo y resulta en la necesidad de actualizar esta clave, no hay una forma fácil de notificar al sistema para actualizar esta clave de sesión. Posiblemente no sea gran cosa, pero algo de lo que debes estar consciente.

Answer 7

Hay algunos factores que deberá tener en cuenta al decidir dónde almacenar los datos temporales. El almacenamiento de la sesión es ideal para datos específicos de un solo usuario. Si encuentra que el controlador predeterminado de almacenamiento de sesión basado en archivos es ineficiente, puede implementar algo más, posiblemente utilizando una base de datos o un tipo de servidor de Memcache. Ver session_set_save_handler para más información.

Encuentro que es una mala práctica almacenar datos comunes en la sesión de un usuario. Hay mejores lugares para almacenar datos a los que muchos usuarios accederán con frecuencia y, al almacenar estos datos en la sesión, se duplicarán los datos para cada usuario que necesite estos datos. En su ejemplo, puede configurar un tipo diferente de motor de almacenamiento para esta información de onda (basada en wave_id) que NO está vinculada específicamente a la sesión de un usuario. De esta forma, extraerá los datos una vez y los almacenará en algún lugar para que varios usuarios puedan acceder a los datos sin necesidad de otra extracción.

Answer 8

He encontrado que las sesiones son muy útiles, pero hay que tener en cuenta algunas cosas:

1) Que PHP puede almacenar sus sesiones en una carpeta tmp u otro directorio que pueda ser accesible para otros usuarios en su servidor. Puede cambiar el directorio donde se almacenan las sesiones yendo al archivo php.ini.

2) Si está configurando un sistema de alto valor que necesita una seguridad muy estricta, es posible que desee encriptar los datos antes de enviarlos a la sesión y descifrarlos para usarlos. Nota: esto podría generar demasiada sobrecarga dependiendo de la capacidad de tráfico / servidor.

3) He encontrado que session_destroy (); no elimina la sesión de inmediato, aún tiene que esperar que el recolector de elementos no utilizados de PHP limpie las sesiones. Puede cambiar la frecuencia con la que se ejecuta el recolector de elementos no utilizados en el archivo php.ini. Pero todavía no parece muy confiable, más información http://www.captain.at/howto-php-sessions.php

Answer 9

Las variables de Sesión de pozo son realmente una de las únicas formas (y probablemente la más eficiente) de tener estas variables disponibles durante todo el tiempo que el visitante está en el sitio web, no hay manera real para que el usuario las edite (que no sea un exploit en su código, o en el intérprete de PHP) por lo que son bastante seguros.

Es una buena manera de almacenar configuraciones que el usuario puede cambiar, ya que puede leer las configuraciones de la base de datos una vez al comienzo de una sesión y está disponible para esa sesión completa, solo necesita hacer más llamadas a la base de datos si la configuración se cambian y, por supuesto, como se muestra en el código, es trivial para saber si la configuración ya existe o si deben extraerse de la base de datos.

No puedo pensar en ninguna otra forma de almacenar variables temporales de forma segura (ya que las cookies se pueden modificar fácilmente y esto no será deseable en la mayoría de los casos), así que $ _SESSION sería el camino a seguir.

Answer 10

OMI, es perfectamente aceptable almacenar cosas en la sesión. Es una excelente forma de hacer que los datos sean persistentes. También es, en muchos casos, más seguro que almacenar todo en las cookies. Aquí hay algunas preocupaciones:

• Es posible que alguien pueda secuestrar una sesión, por lo que si va a utilizarla para realizar un seguimiento de la autorización del usuario, tenga cuidado. Lea this para más información.
• Puede ser una forma muy perezosa de guardar datos. No solo arroje todo en la sesión para que no tenga que consultarla más tarde.
• Si va a almacenar objetos en la sesión, se deberán incluir sus archivos de clase antes de que la sesión se inicie en la próxima solicitud o deberá haber configurado un cargador automático.

Answer 11

Otra forma de mejorar la validación de entrada es emitir la variable _GET [''wave_id'']:

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".(int)$_GET[''wave_id'']." LIMIT 1";

Supongo que wave_id es un número entero, y que solo hay una respuesta.

Será

Answer 12

Si está ejecutando en su propio servidor, o en un entorno donde nadie puede husmear en sus archivos / memoria en el servidor, los datos de la sesión son seguros. Se almacenan en el servidor y solo se envía una cookie de identificación al cliente. El problema es si otras personas pueden arrebatar la cookie y hacerse pasar por otra persona, por supuesto. Usar HTTPS y asegurarse de no colocar la ID de la sesión en las URL debe mantener a los usuarios a salvo de la mayoría de esos problemas. (XSS aún puede ser usado para robar cookies si no tiene cuidado, vea la publicación de Jeef Atwoods sobre esto también).

En cuanto a qué almacenar en una variable de sesión, coloque sus datos allí si desea volver a consultarlos en otra página, como una cesta de la compra, pero no los coloque allí si solo se utilizan datos temporales para producir el resultado de esto. página, como una lista de etiquetas para la publicación actualmente vista. Las sesiones son para datos persistentes por usuario.

Answer 13

Uso este enfoque un poco, no veo ningún problema con eso. A diferencia de las cookies, los datos no se almacenan en el lado del cliente, lo que a menudo es un gran error.

Sin embargo, como todo, tenga cuidado de que siempre esté desinfectando la entrada del usuario, especialmente si está ingresando datos del usuario en la variable $ _SESSION, y luego usando esa variable en una consulta SQL.

Answer 14

Uso la variable de sesión todo el tiempo para almacenar información para los usuarios. No he visto ningún problema con el rendimiento. Los datos de la sesión se basan en la cookie (o PHPSESSID si tiene las cookies desactivadas). No veo que sea más un riesgo de seguridad que cualquier otra autenticación basada en cookies, y probablemente sea más seguro que almacenar los datos reales en la cookie de los usuarios.

Sin embargo, para hacerte saber, tienes un problema de seguridad con tu declaración de SQL:

SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=".$_GET[''wave_id''];

NUNCA, NO REPETIO NUNCA , tome los datos proporcionados por el usuario y úselos para ejecutar una declaración SQL sin antes desinfectarla. Me gustaría envolverlo entre comillas y agregar la función mysql_real_escape_string() . Eso lo protegerá de la mayoría de los ataques. Entonces tu línea se vería así:

$query_taskinfo = "SELECT participationcode, modulearray, wavenum FROM mng_wave WHERE wave_id=''".mysql_real_escape_string($_GET[''wave_id''])."''";

Answer 15

Zend Framework tiene una biblioteca útil para la administración de datos de sesión que ayuda con la caducidad y la seguridad (para cosas como captchas). También tienen una explicación útil de las sesiones. Ver http://framework.zend.com/manual/en/zend.session.html