中央认证服务(cas )集中式认证服务是一种广泛使用的单点登录协议，尤其是在校园网和企业网络中，用户只需向认证服务器提供一次证书即可实现多个APP应用这样，用户在登录到APP应用程序时就不需要进行重复验证，也就无法获得口令等敏感信息。
在上一篇文章中，我们学习了使用Scrapy框架检索数据。 其中之一是在登录后获取数据。 那篇文章简要说明了登录。 本文举例说明了如何使用python实现CAS认证登录。 登录完成后，攀登数据也是水路。
本文将在以下三个部分依次展开。
我们首先理解CAS协议的流程，储备知识。 然后结合实例网站进行分析，加深理解进行编码的实现、验证。 学习CAS协议过程
用于首次访问Web服务的协议流程如下：
步骤1，浏览器正常启动Web服务请求(有过期的cookie或没有cookie ) )。
步骤2、web服务发现cookie无效，重定向到CAS登录界面进行认证
步骤3，用户填写认证信息后，将认证信息开机自检至CAS服务器
在步骤4中，CAS服务器确定认证信息有效，生成Cas-cookie并返回一次性有效ticket
步骤5，浏览器保存cas-cookie，拿ticket再次访问web服务
在步骤6中，web服务要求CAS服务器确保ticket有效
步骤7，CAS验证ticket有效后，CAS删除ticket，并将结果返回web服务
在步骤8中，web服务生成服务-cookie并向浏览器返回web资源
第二次访问同一Web服务
如上图所示，第一次访问时在步骤8中返回的服务-cookie用于浏览器访问同一站点的web服务。 也就是说，要求CAS认证无效。
第二次访问不同的Web服务
协议流程类似于“首次访问web服务”，不同之处在于，在步骤2重定向时，浏览器在访问重定向cas服务器时会携带cas-cookie，而cas服务器会携带cookie 这里不再写流程图了。
浏览器捕获分析
传统规则使用浏览器F12开发人员工具分析web包。 请求相应的pkgManage资源时，将返回302个状态：重定向，重定向地址显示在响应标头的Location域中，如下图所示。 通过查看位置值，可以验证是否重定向到cas服务登录界面。 此外，它还具有一个service参数，用于指示浏览器原来访问的服务站点(以便在cas验证后正确跳转并返回)。
如下图所示，输入用户名、密码登录后，系统会发送开机自检请求，提示请求正文中存在用户名、密码。 但是，除了用户名密码外，还有三个字段_eventid、execution和lt，不知道它们来自哪里。
通常，它们是登录表单中的隐藏字段，服务器验证开机自检请求中的这些字段必须与登录接口匹配，以避免暴力破解(与验证码有点类似)。 在登录界面元素中用关键字搜索，果然能找到。 编码时，可以使用XPATH语句获取相应的值(请参阅以前的我的scrapy系列文章)。
CAS认证成功后，返回重定向的地址，并具有参数ticket。 然后访问这个地址。 我带ticket。 网站希望CAS服务验证此ticket是否有效。
如下图所示，如果ticket身份验证成功，重定向地址将指向第一个请求的资源，并配置服务-cookie。
编码实现
因为完整的流程中存在service-cookie和cas-cookie，所以我们的casService中也定义了两个session。 其中，svr_session由外部服务传递，cas_session在类内部管理。 初始化时从文件中加载cookie。
逻辑实现如下。 集合上的分析过程，代码逻辑很容易理解，所以这里不做说明。
本文以Python为例，逐步分析并实践实现了CAS登录的实例。 大家可以在校园网或企业网上实践。 其实在理解协议原理，结合包分析加深理解后，编码就是水到渠成。 由于篇幅限制，如果需要完整的示例代码，可以在https://download.csdn.net/download/zhutou _ Xu/15498630上免费下载cas_service.rar。 如果有疑问，请在评论区留言。 之后会发布更多的python实战分享，喜欢的请夸奖关注。