Take sessionID For example , it is through the medium of this cookie identifies key-value (to achieve user authentication) is passed between the browser and the server, in order to achieve sustained `browser and server communications`
cookie main attributes:
path: the cookie the scope: '/' denotes all current url domain, can access to the Cookie
domain: Cookie field [returned by the server, the browser stores]
the expire: Cookie expiration time
<?php
//cookie跨域问题讨论
//关于sessionID, 媒介:通过cookie这种key-value标识(实现用户身份认证)在浏览器和服务器间进行传递,从而实现通讯,
// cookie的主要属性:
// path:cookie的作用域 如:'/'表示当前域名的所有url下,均可访问到该cookie
// domain:cookie域[由服务器返回,浏览器端存储]
// expire:cookie的过期时间
/** 测试说明
* 主机域名为www.caibird.top 而http头设置的cookie域名为www.weibo.com
*/
//测试场景:
// case 1: 在初次访问时打开flag-a, 二次访问关闭
// case 2: 在初次访问时关闭flag-a, 二次访问打开
//测试一 通过设置cookie的domain域, 观察浏览器端如何响应
#flag-a
// ini_set('session.cookie_domain', 'weibo.com');
#flag-a
session_start();
$timestamp = time();
if (!isset($_SESSION['hope'])) {
$_SESSION['hope'] = $timestamp . ': hope for you!';
}
//测试结论
// case 1: 初次访问该网页时,浏览器并没有存储sessionID,原因(猜测)是访问域名与cookie域名的domain属性值不等时,浏览器会拒绝存储该cookie, 但是在(flag-a注释关闭)之后二次访问时, 服务器又会与浏览器成功建立的会话[使用cookie在服务器与浏览器之间建立可持续通讯(不是网络上的tcp断开和tcp连接)]
// case 2: 服务器与浏览器间的会话成功建立[cookie成功保存在浏览器端], 之后再(flag-a注释打开), 发现保存的cookie并没有消失, 原因是因为sessionID这个cookie的expire属性为"session"(即浏览器关闭后, sessionID会丢失, 即该cookie是存在内存中并而非存到磁盘上)
//结论:
// 只要认清cookie的本质及其属性,理解浏览器和服务器的会话机制, 再充分认识cookie在浏览器端的存储机制, 就能较好的实现浏览器与服务器间的`通讯`；
// 且在某一层面上, 浏览器本身就支持跨域这种行为, 且考虑到网页使用安全, 浏览器支持安全策略-“同源策略”, 也不允许访问不同源(不同域名)下的资源。
//附赠:其他测试方法, 观察浏览器端是否有存储相关cookie, 及其path, expire等属性
// 通过setcookie方式
setcookie('where', 'hello kiti', time()+60, '/', '.caibird.top');
setcookie('come', 'here', time()+60, '/', '.caibird.top');
setcookie('zore', 'here', time()+60, '/', '.weibo.com');
echo json_encode($_SESSION); //打印会话<?phpTest results
Case 1 : The first time you visit the page, the browser does not store sessionID, because the domain property value access domain with the cookie domain name does not match, the browser will refuse to store the cookie, but the (flag-a comment closed) after when the second visit, the browser and the server will successfully established session [ use the cookie to establish sustainable communication (tcp tcp connection and disconnection is not on the network) between server and browser ]
Case 2: between the server and the browser the session is successfully established [cookie successfully saved in the browser], and then again (flag-a comment open), find the saved cookie has not disappeared, the reason is because expire attribute sessionID this cookie is "session" (ie, the browser closes after, sessionID will be lost, that is, the cookie is stored in memory and on disk rather than stored)
Conclusion:
As long as the cookie recognize the nature of their properties, understanding mechanisms session browser and the server, and then fully aware of the cookie in the browser side storage mechanism, will be able to achieve `good communication between the browser and the server ';
and in on one level, the browser natively supports cross-domain such behavior, and taking into account the use of web security, browser support security policy - "same origin policy" does not allow access to resources in different sources (different domain).
Someone is bound to ask: is not the same as long as the cookie domain settings and access the host name is not on it (I have not tried this), the browser's same-origin policy check may not be so simple (I think so of)? Or the cookie domain is actually superfluous (domain names grade) just is not homologous to check on the line, there are many means of thing can only say that there is a cookie domain attribute is necessary (to believe that a master).
We can not easily get bogged down in the details, but we can learn together to discuss.
