Python/Django升级后djangosaml2认证成功却为匿名用户，会话ID未存库

结合版本升级带来的框架行为变更，ACS接口返回session_id但数据库无对应会话记录的现象，本质是Django会话持久化机制未被正常触发，和当前的版本组合直接相关：

• Django 1.11明确了会话持久化规则：只有当session对象被标记为modified时，才会在响应返回时将内容写入数据库，空的新生成session不会触发写入逻辑
• djangosaml2 0.17.2为适配Python2.7+Django1.9开发的版本，在Python3.8+Django1.11组合下，ACS流程中调用django.contrib.auth.login()的步骤容易出现静默异常，导致login()逻辑未真正执行，自然不会给session打上修改标记，也不会写入用户关联信息
• 中间件配置迁移不完整会放大上述问题：从Django1.10开始框架废弃了旧的MIDDLEWARE_CLASSES配置项，如果升级时没有完整迁移中间件配置，会导致SessionMiddleware运行逻辑和新框架的会话机制不匹配，即便生成了session cookie也无法触发正常持久化
• 回退pysaml2版本无法解决问题的现象，本身也印证了问题不在pysaml2的认证逻辑，而是在djangosaml2和升级后Django的会话交互层

• 检查中间件配置合规性
  • 移除配置文件中遗留的旧版MIDDLEWARE_CLASSES定义，所有中间件统一使用Django1.11要求的MIDDLEWARE列表配置
  • 保证django.contrib.sessions.middleware.SessionMiddleware处于中间件列表靠前位置，排在AuthenticationMiddleware、CommonMiddleware等依赖会话的中间件之前
  • 手动在Django Shell中测试会话写入能力：执行from django.contrib.sessions.backends.db import SessionStore; s = SessionStore(); s['test']='123'; s.save()，确认数据库session表可以正常写入，排除数据库权限、表结构不兼容的底层问题
• 定位ACS流程的静默异常
  • 临时将djangosaml2、django.contrib.auth模块的日志级别调整为DEBUG，复现ACS认证流程，查看日志中是否存在被上层逻辑捕获的未处理异常——常见异常包括Python3环境下的类型不匹配、序列化失败等，这类异常会导致login()流程中断，不会给session打上修改标记
  • 在ACS视图执行重定向逻辑前，临时插入强制修改session的测试代码：request.session['debug_test'] = '1'，如果插入这行代码后session可以正常写入数据库、用户可以正常登录，即可确认问题来自login()流程未触发会话修改标记
• 适配版本兼容问题
  • 针对djangosaml2 0.17.2和Django1.11的兼容缺口，最直接的临时修复方式是在ACS视图的重定向前，手动执行request.session.save()强制触发会话持久化，验证修复效果
  • 如果确认是login()流程因为Python3的类型兼容问题中断，需要调整用户ID的类型处理逻辑，避免因为类型不匹配导致session序列化失败
  • 0.17.2版本的djangosaml2原生支持范围仅覆盖到Django1.10，在更高版本的Django和Python组合下存在已知的会话处理缺陷，不建议长期强行适配过低版本组件

内容的提问来源于stack exchange，提问作者OritK