Si tenía un usuario conectado a mi sitio, con su identificación almacenada $_SESSION, y desde su navegador, hacía clic en el botón 'Guardar' que haría una solicitud AJAX al servidor. ¿ $_SESSIONSe guardarán sus cookies y las suyas en esta solicitud, y puedo confiar con seguridad en que la identificación esté presente en el $_SESSION?
Respuestas:
La respuesta es sí:
Las sesiones se mantienen del lado del servidor. En lo que respecta al servidor, no hay diferencia entre una solicitud AJAX y una solicitud de página normal. Ambas son solicitudes HTTP, y ambas contienen información de cookies en el encabezado de la misma manera.
Desde el lado del cliente, las mismas cookies siempre se enviarán al servidor, ya sea una solicitud regular o una solicitud AJAX. El código Javascript no necesita hacer nada especial o incluso para estar al tanto de esto, simplemente funciona igual que con las solicitudes regulares.
Warning: session_write_close(): Failed to write session data (user)Últimamente recibí un error de forma intermitente en un proyecto, pero solo cuando la solicitud de AJAX ocurre durante la carga del resto de la página. Estoy usando una base de datos MySQL para los datos de la sesión, y es posible que la solicitud de la página principal bloquee esa tabla, evitando que la solicitud AJAX acceda a ella.
Si el archivo PHP que solicita AJAX tiene una session_start()información de sesión, se conservará. (mostrando las solicitudes están dentro del mismo dominio)
Lo que realmente quiere decir es: ¿se envían cookies con la solicitud de AJAX? Suponiendo que la solicitud de AJAX es para el mismo dominio (o dentro de las restricciones de dominio de la cookie), la respuesta es sí. Entonces, las solicitudes de AJAX al mismo servidor retienen la misma información de sesión (suponiendo que los scripts llamados emiten un session_start () como cualquier otro script PHP que desee acceder a la información de la sesión).
Pues no siempre. Usando cookies, eres bueno. Pero el "puedo confiar con seguridad en que la identificación esté presente" me instó a extender la discusión con un punto importante (principalmente como referencia, ya que el recuento de visitantes de esta página parece bastante alto).
PHP puede configurarse para mantener sesiones reescribiendo URL, en lugar de cookies. ( Cómo es bueno o malo (<- vea, por ejemplo, el comentario más importante allí) es una pregunta separada , ahora sigamos con la actual, con solo una nota al margen: el problema más destacado con las sesiones basadas en URL: lo evidente visibilidad de la ID de sesión desnuda: no es un problema con las llamadas internas de Ajax; pero luego, si está activado para Ajax, también está activado para el resto del sitio, así que allí ...)
En el caso de las sesiones de reescritura de URL (sin cookies), las llamadas de Ajax deben ocuparse de que sus URL de solicitud estén correctamente diseñadas. (O puede implementar su propia solución personalizada. Incluso puede recurrir al mantenimiento de sesiones en el lado del cliente , en casos menos exigentes). El punto es la atención explícita necesaria para la continuidad de la sesión, si no utiliza cookies:
Si el Ajax llama solo extraen las URL textualmente del HTML (tal como se reciben de PHP), eso debería estar bien, ya que ya están cocinadas (umm, cookified).
Si necesitan ensamblar los URI de solicitud ellos mismos, la ID de sesión debe agregarse a la URL manualmente. (Marque aquí , o las fuentes de la página generadas por PHP ( con reescritura de URL activada ) para ver cómo hacerlo).
De OWASP.org :
Efectivamente, la aplicación web puede usar ambos mecanismos, cookies o parámetros de URL, o incluso cambiar de uno a otro (reescritura automática de URL) si se cumplen ciertas condiciones (por ejemplo, la existencia de clientes web sin soporte de cookies o cuando las cookies no son aceptado debido a preocupaciones de privacidad del usuario).
De un foro Ruby publicación en el :
Cuando se usa php con cookies, la ID de sesión se enviará automáticamente en los encabezados de solicitud incluso para Ajax XMLHttpRequests. Si usa o permite sesiones php basadas en URL, deberá agregar el ID de sesión a cada URL de solicitud de Ajax.
Es muy importante que las solicitudes AJAX retengan la sesión. El ejemplo más fácil es cuando intenta hacer una solicitud AJAX para el panel de administración, digamos. Por supuesto, protegerá la página a la que realiza la solicitud, a la que no podrán acceder otras personas que no tengan la sesión que obtiene después de iniciar sesión como administrador. ¿Tiene sentido?
Sin embargo, una cosa a tener en cuenta, especialmente si está utilizando un marco, es verificar si la aplicación está regenerando los identificadores de sesión entre solicitudes: cualquier cosa que dependa explícitamente de la identificación de la sesión tendrá problemas, aunque obviamente el resto de los datos en la sesión no se verá afectada.
Si la aplicación está regenerando identificadores de sesión como este, puede terminar con una situación en la que una solicitud ajax invalida / reemplaza el ID de sesión en la página solicitante.
Eso es lo que hacen los frameworks, por ejemplo, si inicializa la sesión en Front Controller o secuencia de comandos boostrap, no tendrá que preocuparse por su inicialización ni para los controladores de página ni para los controladores ajax. Los frameworks PHP no son una panacea, ¡pero hacen muchas cosas útiles como esta!
ponga su sesión () autenticación en todas las páginas del lado del servidor aceptando una solicitud ajax:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwiseesa es la única forma en que lo he hecho.
HttpOnlybandera al configurar una cookie, lo que significa que su Javascript no podrá ver la cookie. Sin embargo la cookie será todavía ser enviado tanto para AJAX y solicitudes de páginas regulares y seguir trabajando exactamente lo mismo. Tu Javascript simplemente no lo verádocument.cookie.