出现过时的Authorization请求头 我们多测试几次，故意输入错误的用户名密码，观察浏览器控制台，发现浏览器 登录过后，再次发送请求， 浏览器会自动携带上次的 Authorization 请求头。 Authorization: Basic MTExOjExMTE= ==> 111:1111 , 为什么我随便输入错误的， 请求头却也是 这个值？ 看清楚啊 登录成功后， 下次再访问 Basic认证保护的url， 不再要求输入认证信息。 F12 查看， 反 base64 解码， 可以看到那个是aaa:bbbb， 是错误的。 但是不影响其正确性。 why 观察发现，认证成功后， 便会使用第一次认证输入的 那个Authorization请求头，即使它是错的。大概是一种缓存机制。 如何退出登录？ 多次测试， 如果不执行退出，那么关掉tab 是不行的，重启服务器不行， 必须浏览器关闭后 重新打开才可以。必须要 重启浏览器才会清除那个请求头，否则就一直使用之前登陆成功的旧的相同的请求头。 我发现，其实是没有开发退出登录的手段。 可以这样做： 如果前端发起了 logout 请求，后端把 对应的认证信息删除，下次过来检查 sessionId，如果未登录，那么返回 401. 浏览器控制台捕捉不到的请求 有时候刷新浏览器，发现控制台只发出了一次请求，但是呢， 服务端却打印了多个认证的日志。为何？ 难道浏览器有控制台捕捉不到的请求? 仔细测试发现， 确实是这样的。 其实 第一次正确登录的时候， 看似一次www Authorization 认证， 其实发起了两个请求， 第一次的Authorization 正是 YWFhOmJiYmI= ， aaa:bbbb 。 我们通过抓包工具来观察： 第二次，才是 后端的 认证配置 我们在浏览器地址栏发起一次请求，可以观察到抓包工具中出现了4个数据包（也就是两次http请求，一个请求一个来回两个数据包），感觉怪怪的， 不太正常吧这个是为什么呢？ 多次测试，观察发现，这个其实也不是一定这样的。 有时候呢，也是正常的，也就是 一次浏览器请求就来回两个数据包 。 如果第一次就输入正确的用户名密码，就不会这样。 在这个大概是因为， 浏览器会使用之前旧的Authorization请求头。浏览器存在缓存。也可以认为是有一种 保护 策略。但重启浏览器之后， 是不会发送上次的 authen 请求头的。 如果第一次就不输入正确的用户名密码，就会出现奇怪的现象。或者我们修改一下 认证的用户名密码，会发现浏览器发出的请求，还是使用之前旧的Authorization请求头， 这样就会出现 一次浏览器请求，抓包抓到了2个请求，4个数据包。 每次认证失败，都会返回响应401 可以看到status 字段， 有的是401， 有的是 （failed）， 但是其实点进去打开发现 都是401,： 第一次访问， 返回返回401， 并弹出 认证框。 每次认证失败 都弹出。 但是每次的输入， 不一定是 请求头里面的那个， 大概因为被保护了。 实际发出的请求， 可能 要多一次。 对路径的认证 我在认证的时候，发现我仅仅是对 /pathA/req1 路径进行了认证的拦截配置，但是发现对其他的非pathA开头路径的请求就不会携带authorization请求头，对 /pathA/ 开头的其他的地址则会携带。why？ 比如， /enumm 路径下的请求有请求头 authorization = Basic dXNlcjE6MTIz ， 其他的没有; 是get 请求 都不需要吗 不是， 是因为 enumm/basicTest 的存在，导致了所有的 enumm/* 请求都会携带请求头 Authorization: Basic YTph //@EnableNacos(globalProperties = null) 怎么解释呢，不好解释。记住就好，大概就是浏览器的认证机制吧。 为什么authorization请求头是Basic 开头 authorization 请求头是固定authorization， 这个可以理解，但是其值固定是 Basic realm=xxx 吗？ 测试发现，可以是小写basic，但不能是Basi, 也不能不写； 而后面的格式是realm=xxx, 可以随意写， 比如aa=a， 但是= 不能省去。 固定是Basic 开头，估计是为了区分其他的各种其他类型的authorization认证。
#yyds干货盘点# BASIC认证的一些疑问
