servidores registros que nombre informatica ejemplo dominio definicion session url dns ip domain-name

session - registros - servidores de dominio



La sesión es específica para qué? ¿Por qué no tratar la sesión de IP y nombre de dominio de la misma manera? (2)

Quiero saber que la sesión es específica con qué? Esto no se restringe a un idioma. Bellow solo usa php como ejemplo.

Uso la sesión de php, funciona bien cuando uso el nombre de dominio de mi sitio web. Para probar el sitio web en mi vmvare ubuntu local en el sistema operativo Windows, cambio los hosts de mis ventanas para convertir el DNS a mi ip local. Cuando realizo la prueba local, uso el nombre de dominio, también funciona bien. Pero cuando cambio la URL en el navegador a Ip, la sesión se pierde.

Puede confundir por qué hago esto, porque también quiero probar la página en mi dispositivo Android, ya que no puedo cambiar el archivo de hosts de mi dispositivo Android sin la raíz de Android, así que tengo que usar ip.

También puede confundir por qué no uso la ip todo el camino? Porque uso un tercer inicio de sesión abierto en mi aplicación web. El tercer mástil de inicio de sesión abierto usa el nombre de dominio como la URL de redireccionamiento, por lo que cuando inicie sesión, se redirigirá a la url en el formato de nombre de dominio.

¿Por qué la sesión de PHP es la misma cuando el nombre de dominio y la ip?

Para asegurarse de que la sesión de PHP no es lo mismo con el nombre de dominio y la ip? También probé mi sistema de administración, superior es el sistema de usuario.

También pruebo mi sistema de administración, puedo usar la ip para iniciar sesión en todo momento. Pero cuando cambio la dirección IP al nombre de dominio en la url, la sesión también pierde.


La razón de este comportamiento es la siguiente:

Cuando se crea una sesión, su ID de sesión se almacena en una cookie. El servidor envía el valor de la cookie en el campo HTTP Set-Cookie .

En la siguiente solicitud del cliente al servidor, esta identificación de sesión se envía de vuelta al servidor en el campo HTTP Cookie . Pero el agente de usuario (navegador) debe enviar la cookie solo bajo ciertas condiciones. Básicamente, el dominio almacenado con la cookie debe coincidir con el dominio del servidor. Pero, de hecho, la regla es mucho más compleja y se define en el RFC 6265 de la siguiente manera:

El agente de usuario DEBE usar un algoritmo equivalente al siguiente
algoritmo para calcular la "cookie-string" de una tienda de cookies y una
solicitud-uri:

  1. Deje que cookie-list sea el conjunto de cookies de la tienda de cookies que cumple con todos los requisitos siguientes:

    • Ya sea:

      El distintivo de host de la cookie es verdadero y el host de solicitud canonicalizado es idéntico al dominio de la cookie.

      O:

      El host-only-flag de la cookie es falso y el dominio canishicalized request-host-coincide con el dominio de la cookie.

    • La ruta de acceso de la solicitud-uri coincide con la ruta de la cookie.

    • Si la bandera de solo-seguridad de la cookie es verdadera, entonces el esquema de solicitud-uri debe denotar un protocolo "seguro" (según lo definido por el agente de usuario).

      NOTA: La noción de un protocolo "seguro" no está definida por este documento. Por lo general, los agentes de usuario consideran que un protocolo es seguro si el protocolo hace uso de la capa de transporte

seguridad, como SSL o TLS. Por ejemplo, la mayoría de los agentes de usuario consideran que "https" es un esquema que denota un protocolo seguro.

  • Si el indicador de solo-cookies de la cookie es verdadero, entonces excluya la cookie si la cadena de cookies se está generando para una API "no HTTP" (según lo definido por el agente de usuario).

Si no tiene el coraje de leer todo el RFC6265 y los RFC relacionados, puede hacer algunos experimentos en su navegador y mirar los encabezados HTTP y las cookies almacenadas en diferentes situaciones. En Firefox, puedes observar esto, por:

  • presionando CTRL + MAYÚS + K
  • haga clic en la pestaña de red
  • recarga la página
  • haga clic en una solicitud

Como mencionas PHP, incluiré información del manual de PHP. Creo que otros lenguajes se comportan de manera similar.

En el servidor, una sesión es específica de una cookie. Desde el manual de PHP :

Los ID de sesión normalmente se envían al navegador a través de las cookies de sesión y el ID se utiliza para recuperar los datos de sesión existentes. La ausencia de una ID o cookie de sesión le permite a PHP saber crear una nueva sesión y generar una nueva ID de sesión.

En el agente de usuario (el cliente, generalmente un navegador), una cookie es específica de un dominio y ruta. De RFC6265 , sección 4.1.2.3:

El atributo de dominio especifica los hosts a los que se enviará la cookie. Por ejemplo, si el valor del atributo de Dominio es "ejemplo.com", el agente de usuario incluirá la cookie en el encabezado Cookie al realizar solicitudes HTTP a example.com, www.example.com y www.corp.example. com.

Sección 4.1.2.4:

El agente de usuario incluirá la cookie en una solicitud HTTP solo si la porción de ruta de la solicitud-uri coincide (o es un subdirectorio) con el atributo de ruta de la cookie, donde el carácter% x2F ("/") se interpreta como un separador de directorio .

Por lo tanto, si mueve hacia adelante y hacia atrás desde el nombre de dominio a la dirección IP, por ejemplo, example.com y 12.34.56.78 , una cookie de sesión creada por el servidor para example.com no será enviada por el agente de usuario si usted hace más adelante una solicitud a 12.34.56.78 , incluso si ambos son el mismo servidor. Con la solicitud posterior, dado que el servidor no ve ninguna cookie de sesión, se crea una nueva sesión y se envía una nueva. Es por eso que usar el nombre de dominio y la dirección IP usará sesiones separadas.

Si necesita usar la misma sesión cuando utiliza tanto el nombre de dominio como la dirección IP, debe conservar la ID de sesión entre las solicitudes. Un método común es pasar el ID de sesión en la cadena de consulta. La administración de sesiones PHP, de hecho, también se puede configurar para usar este método, pero nunca necesito usarlo, así que no puedo decirte cómo va a funcionar.

Continuando con mi ejemplo, puede usar esto para solicitudes posteriores:

http://12.34.56.78/?sessionId=abcdef0123456789

Donde abcdef0123456789 es un ID de sesión de ejemplo.

En el código PHP, configure la ID de sesión antes de llamar a session_start() . Código de ejemplo:

if(isset($_GET[''sessionId''])) session_id($_GET[''sessionId'']); @session_start();

Por supuesto, no tiene que usar sessionId . Puedes usar foobar o cualquier otra cosa. También puede cambiarlo diariamente o incluso cada hora para evitar el secuestro de la sesión.

Actualización: Para usar foobar , modifique el código PHP a este:

if(isset($_GET[''foobar''])) session_id($_GET[''foobar'']); @session_start();

Con ese código, puede pasar la identificación de la sesión de esta manera:

http://12.34.56.78/?foobar=abcdef0123456789

Si quiere usar xyz , el código PHP sería:

if(isset($_GET[''xyz''])) session_id($_GET[''xyz'']); @session_start();

Puede pasar la identificación de la sesión de esta manera:

http://12.34.56.78/?xyz=abcdef0123456789

El punto es que realmente depende de usted.