HTTP协议是无状态的,因此,若不借助其他手段,远程的服务器就无法知道以前和客户端做了哪些通信.Cookie就是“其他手段”之一。饼干一个典型的应用场景,就是用于记录用户在网站上的登录状态。
-
<李>用户登录成功后,服务器下发一个(通常是加密了的)饼干文件。
<李>客户端(通常是网页浏览器)将收到的饼干文件保存起来。
<李>下次客户端与服务器连接时,将饼干文件发送给服务器,由服务器校验其含义,恢复登录状态(从而避免再次登录)。
当浏览器作为客户端与远端服务器连接时,远端服务器会根据需要,产生一个SessionID,并附在Cookie中发给浏览器。接下来的时间里,只要饼干不过期,浏览器与远端服务器的连接,都会使用这个SessionID;而浏览器会自动与服务器协作,维护相应的饼干。
在<代码> 中,请求也是这样。我们可以创建一个<代码>请求。会话> 请求会自动为我们维护好。
发布方法可以将一组用户数据,以表单的形式发送到远端服务器。远端服务器接受后,依照表单内容做相应的动作。
调用<代码> 请求的发布方法时,可以用<代码> 数据参数接收一个Python字典结构。<代码> 请求会自动将Python字典序列化为实际的表单内容,例如:
模拟登录的第一步,首先是要搞清楚我们用浏览器登录时都发生了什么。
GitHub登录页面是https://github.com/login。我们首先清空浏览器饼干记录,然后用Chrome打开登录页面。填入用户名和密码之后,我们打开夯铬和铬的元素审查工具(找到网络标签页),之后点登录按钮。
在夯Chrome中,我们发现,虽然登录页面是https://github.com/login,但实际接收表单的是https://github.com/session。若登录成功,则跳转到https://github.com/首页,返回状态码<代码> 200 。
而在Chrome的审查元素窗口中,我们可以看到提交给会话<代码> 接口的表单信息。内里包含
-
<李>提交
<李> utf8李
<李> authenticity_token李
<李>登录
<李> 密码
其中,<代码> 和<代码> utf8> 登录和<代码>密码> authenticity_token 是一长串无规律的字符,我们不清楚它是什么。
后动作发生在与会话<代码> 接口交互之前,因此可能的信息来源只有<代码>登录接口。我们打开登录页面的源码,试着搜索<代码> authenticity_token>
原来,所谓的<代码> authenticity_token> 隐藏模式隐藏起来了。为此,我们只需要使用Python的正则库解析一下,就好了。python请求模拟登陆github的实现方法
