问题场景：在接口请求中(在登录接口遇到过)，因为网关拦截出现401权限异常，问了下后端说请求头新加了
Authorization: Basic base64(帐号:密码)安全校验，但是不知道为什么会出现弹框要求输入账号密码，不知道是什么逻辑
问题解决
无所不知的互联网啊，告诉我为啥要使用这种没用又不可控的东西
-
第一思路就是没有思路，虽然感觉是
http 401导致浏览器反应的，但是之前没有遇到过这种问题，当然，实际上后端也不应该这样告诉前端，因为不可控 -
问了一圈，终于找到根源问题，也就是
http-Authorization验证模式，这种和浏览器约定的模式，服务器告诉浏览器这种要求之后，浏览器会弹出框让用户填用户名密码，也就是前端的请求没有符合后端的要求才会出现这种问题，也就是在正常的场合根本不会出现这种问题，非正常的场合一般也要符合约定，否则不理 -
是的，那么也就是只要前端加上这个，对用户来说就不会遇到这种问题，而对非用户来说，我开发哪管你怎么玩
-
那直接加上就好了，吗吗吗？开玩笑，我还想问，为什么要加这一层限制，对虽然可以限制客户端，但是实际上限制框架一般都有其余的权限限制，有了更完善的校验之后，这个基础的校验有什么意义？
这里发现实际上token也是同类型校验方式
如果只是想解决问题
-
被某后端搞笑了，我问了一大堆问题，然后他说你加上就行啦，或这是后端配置的问题，让后端关掉就行啦。。。
-
实际上我一直强调，这个问题很好解决，前端加上或后端去掉，实际上对用户来说是无感的，但是我想知道为什么要加上，它的应用场景是什么，加上对于我们框架的意义是什么，如果无意义，那加上是不是会增加风险，什么，没有风险，多一个东西，就要多维护一个东西，某天因为网络问题还是什么问题出现交互问题谁解决。。。
如果只是想解决问题，我们经常都有一定无脑的办法，问题这常常对我来说并不是最好的办法，解决问题的办法最好是发现问题因为什么产生，然后发现为什么有这个问题，然后再去找怎么解决这个问题好，这个过程都是我关注的
这是啥
-
看网上介绍说这是http的一种基础校验模式，http约定被浏览器支持的一种校验规范，当然，这是最基础的，因为安全性等问题，我没看到哪个系统使用它
-
当然不是说这些系统不支持它，实际上跟后端对话中我发现很多系统都是默认支持这种方式的，集成的验证方式有个默认的验证方式，就是
http-Authorization验证模式，但是一般被重写，我们有更完善而灵活可控的方式 -
听说这种系统一般都会默认产生以这种方式作为校验的登录页(未去验证此说法，jsp等系统我比较相信有)，但是一般都会被我们进行自定义登录方式重写，因为我们的验证码验证、域名验证、人机验证、请求次数校验、短信验证等丰富的验证方式导致这种基础的认证被我们抛弃
-
暂时没有发现什么地方用它好，看文章说
SSL或者Kerberos结合这个方式使用，但是这就是后端的工作了，有没有不良好的交互暂时没看到人说，因为真没人用，看说这种简单的校验方式在路由器上用比较多，所以普通路由贼危险，当然时过境迁，这些都没人研究了
后端也没有说有什么比较好的结合方式，所以我也不知道它应该应用在哪里
疑问
听后端说是验证客户端
-
实际上我们既然约定了这种方式，那么我们默认的客户端应该都是有这种请求头的，那就不需要校验了，而担心黑客知道，实际上这个信息是明码的，只要知道我们系统的页面，只要能访问到，都能看到这个请求头，也就是如果以Base64加密的，这跟明码差不多
-
听某后端说可以不用Base64，加强加密效果，因为都是请求头的信息解析，真的？这样不符合约定真的好？然后当出现浏览器调用这个弹框让填用户名密码的时候，又是base64加密的，后端怎么区别。。。没事不要违背规范
-
对于客户端的校验，实际上用这个验证方式并没有多高明，当然直接用可能减少后端的判断，不过后端依旧需要处理其返回逻辑，不能不可控，也就是可以返回
code是401让前端处理，但是http的状态码最好是200(或约定的其他) -
而对于有网关的复杂系统，实际上有非常完善的校验方式，完全没有比较做这等校验，客户端的校验亦是如此
对于使用
-
如果前端只是为了解决这个交互问题，实际上很简单，加上(以后遇到问题解决问题)，或让后端去掉
-
实际上现在也没看到什么人使用了，也很少人会用，问了几个后端都说不出个所以然，要么用就用，要么不用就关了，逻辑太简单，不知道怎么说好
反正对于前端，这是要可控，加上也无所谓，有所谓的是出现异常你要让我可以拦截到
对于这次学习
- 对于这次学习，第一次发现这个问题，还是很有意义的，应该很多这种原生的东西，在框架没有经过过滤处理被默认使用的时候，我们可能就会遇到这种坑，或许这也就是希望自己使用框架有人维护吧
