会话是什么特定的？为什么不将ip和域名会话视为相同呢？

Question

我想知道会话具体是什么？这并不局限于一种语言。Bellow只是以php为例。

我使用php会话，当我使用我的网站域名时，它工作得很好。为了在windows OS上测试本地vmvare ubuntu中的网站，我更改了我的窗口的主机，使DNS成为我的本地ip。当测试本地，我使用域名，它也很好的工作。但是，当我将浏览器中的url更改为Ip时，会话将丢失。

你可能会混淆我为什么要这么做，因为我也想在我的android设备上测试页面，因为如果没有android根，我无法更改我的android设备的主机文件，所以我必须使用ip。

你也可能会搞不懂我为什么不一直使用ip？因为我在我的web应用程序中使用了第三个开放登录。第三种开放登录方式使用域名作为重定向返回url，所以当我登录时，它将以域名格式重定向到url。

为什么当域名和ip时php会话是相同的？

为了确保php会话与域名和ip不一样？我也尝试了我的管理系统，上层是用户系统。

我也尝试我的管理系统，我可以使用ip登录所有的方式。但是当我将ip更改为url中的域名时，会话也会丢失。

Answer 1

由于您提到了PHP，我将包括PHP手册中的信息。我相信其他语言也有类似的表现。

在服务器中，会话是特定于cookie的。来自PHP手册

会话ID通常通过会话cookie发送到浏览器，并且ID用于检索现有的会话数据。缺少ID或会话cookie使PHP知道如何创建新会话，并生成新的会话ID。

在用户代理(客户端，通常是浏览器)中，cookie是特定于域和路径的。来自RFC6265 4.1.2.3节：

域属性指定要将cookie发送到的主机。例如，如果域属性的值为" example.com "，用户代理将在向example.com、www.example.com和www.corp.example.com发出HTTP请求时将cookie包含在Cookie头中。

第4.1.2.4节：

只有当请求-uri的路径部分匹配(或是) cookie的path属性(其中%x2F ("/")字符被解释为目录分隔符)时，用户代理才会将cookie包含在HTTP请求中。

因此，如果您从域名来回移动到IP地址，例如example.com和12.34.56.78，则如果您稍后向12.34.56.78发出请求，则由服务器为example.com创建的会话cookie将不会由用户代理发回，即使两者是同一台服务器。对于后一个请求，因为服务器没有看到会话cookie，所以创建了一个新会话并发送了一个新cookie。这就是为什么使用域名和IP地址将使用单独的会话。

如果在使用域名和IP地址时需要使用相同的会话，则必须保留请求之间的会话ID。一个常见的方法是在查询字符串中传递会话ID。实际上，PHP会话管理也可以配置为使用此方法，但我不需要使用它，所以我无法告诉您将如何进行。

继续我的示例，您可以将其用于后续请求：

http://12.34.56.78/?sessionId=abcdef0123456789

其中abcdef0123456789是一个示例会话ID。

在PHP代码中，在调用session_start()之前设置会话ID。示例代码：

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

当然，您不必使用sessionId。您可以使用foobar或其他任何东西。您还可以每天甚至每小时更改它，以防止会话劫持。

更新：使用foobar，修改foobar代码如下：

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

使用该代码，您可以像下面这样传递会话ID：

http://12.34.56.78/?foobar=abcdef0123456789

如果您想使用xyz，PHP代码将是：

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

您可以像这样传递会话ID：

http://12.34.56.78/?xyz=abcdef0123456789

关键是，这真的取决于你。

Answer 2

造成这种行为的原因如下：

创建会话时，其会话id存储在cookie中。cookie的值由服务器在HTTP字段布奇中发送。

当客户端向服务器发出下一个请求时，此会话id将被发送回饼干字段中的服务器。但是用户代理(浏览器)应该只在某些条件下发送cookie。基本上，与cookie一起存储的域必须与服务器的域匹配。但实际上，规则要复杂得多，在RFC 6265中定义如下：

用户代理必须使用与以下内容等价的算法 从cookie存储区和 请求-uri：

1. 让cookie列表是满足以下所有要求的cookie商店中的cookie集：

- Either:

，cookie的仅存主机标志为真，规范化请求主机与cookie的域相同。

或者：

cookie的仅宿主标志为false，规范化请求--主机域--与cookie的域匹配。

- The request-uri's path path-matches the cookie's path.

- If the cookie's secure-only-flag is true, then the request- uri's scheme must denote a "secure" protocol (as defined by the user agent).

注意:本文档没有定义“安全”协议的概念。通常，如果协议使用传输层，用户代理会考虑协议的安全性。

安全性，如SSL或TLS。例如，大多数用户代理认为"https“是一种表示安全协议的方案。

• 如果cookie的HTTP唯一标志为真，那么如果cookie-字符串是为“非HTTP”API生成的(如用户代理所定义的)，则排除cookie。

如果您没有勇气阅读所有的RFC6265和相关的RFC，您可以在浏览器中进行一些实验，查看不同情况下的headers和存储的cookie。在Firefox中，您可以通过以下方法观察到：

• 击打CTRL+SHIFT+K
• 单击网络选项卡
• 重新加载页面
• 单击请求