如果我有一个用户登录我的网站,将他的id存储在其中$_SESSION
,并且从他的浏览器中点击了一个"保存"按钮,该按钮将向服务器发出AJAX请求.他$_SESSION
和cookie是否会保留在此请求中,我是否可以安全地依赖于$_SESSION
?
答案是肯定的:
会话在服务器端维护.就服务器而言,AJAX请求和常规页面请求之间没有区别.它们都是HTTP请求,它们都以相同的方式在标头中包含cookie信息.
从客户端,无论是常规请求还是AJAX请求,都将始终向服务器发送相同的cookie.Javascript代码不需要做任何特殊的事情,甚至不需要知道这种情况,它只是与常规请求一样.
如果AJAX请求的PHP文件有session_start()
会话信息将被保留.(禁止请求在同一个域内)
你真正得到的是:使用AJAX请求发送的cookie是什么?假设AJAX请求是在同一个域(或在cookie的域约束内),答案是肯定的.因此,返回同一服务器的AJAX请求会保留相同的会话信息(假设被调用脚本根据需要访问会话信息的任何其他PHP脚本发出session_start()).
好吧,并非总是如此.使用cookies,你很好.但是"我能否安全地依赖于存在的身份"促使我以一个重要的观点扩展讨论(主要是为了参考,因为这个页面的访问者数量似乎很高).
PHP可以配置为通过URL重写而不是cookie来维护会话.(它的好坏如何(< - 参见例如最顶层的评论)是一个单独的问题,现在让我们坚持使用当前的一个问题,只有一个侧面说明:基于URL的会话最突出的问题 - 公然裸会话ID的可见性 - 内部Ajax调用不是问题;但是,如果它为Ajax打开,它也会为网站的其余部分打开,所以那里......)
在URL重写(无cookie)会话的情况下,Ajax调用必须自己处理它们的请求URL是否正确制作.(或者您可以推出自己的自定义解决方案.在不太严格的情况下,您甚至可以在客户端维护会话.)重点是会话连续性需要明确的关注,如果不使用cookie:
如果Ajax调用只是从HTML中逐字提取 URL(从PHP收到),那应该没问题,因为它们已经被煮熟了(嗯,煮熟).
如果他们需要自己组装请求URI,则需要手动将会话ID添加到URL.(请在此处查看,或者由PHP生成的页面源(使用URL重写)以查看如何执行此操作.)
来自OWASP.org:
实际上,如果满足某些条件,Web应用程序可以使用机制,cookie或URL参数,甚至可以从一个切换到另一个(自动URL重写)(例如,存在没有cookie支持或不支持cookie的Web客户端)因用户隐私问题而被接受).
来自Ruby论坛帖子:
当使用带cookie的php时,即使对于Ajax XMLHttpRequests,会话ID也会自动发送到请求头中. 如果您使用或允许基于URL的php会话,则必须将会话ID添加到每个Ajax请求URL.