Http Authorization

Basic Authorization 从最初的基本的授权方式说起。 http头里添加：WWW-Authenticate: Basic realm="xxx” 即可要求浏览器输入授权信息。 浏览器发送时会附带授权信息：Authorization:Basic YWRtaW46YWRtaW4= 它是由base64加密的。如上解密后为：admin:admin Basic authorization 的授权方式就是每个请求中在http头里都携带着base64加密的授权信息，服务器在每次收到请求时都要进行权限判断，再执行对应的操作。 由于考虑到授权，那自然涉及到了客户端状态。http /0.9是无状态无连接的协议，一个特定的输入就对应一个特定的输出。由于http 不需要很强的实时性，属于一问一答的对话形式，且有时并发性强，不可能是一对一的专人(线程)负责一个会话。所以如果涉及到状态就不如把状态参数放置在请求中，服务端就要先对请求中携带的状态进行判断，再判断对应的操作是否有权限等等。按数字电路的理论，服务端的业务就变成两段式状态机的组合逻辑部分。状态部分可以保存在客户端或者服务端，这就变成了cookie和session了。 http /1.0增加了keep-alive 选项，http /1.1则默认了所有连接都有keep-alive选项。http keep-alive 选项就是说 发送完响应之后不服务端不主动关闭连接(http /0.9 是会主动关闭连接的)。http 的keep-alive 应该通过是tcp的keep-alive 定时心跳来维持的，不过http的keep-alive 还有一层意思是即使tcp 连接断开了，http的session还是keep alive的，http 可能也维护着一个保活定时器去试探每个连接上的客户端是否仍在线(这个不清楚)。 当http涉及到用户的概念时，就需要识别用户了，可能最早http识别一个客户端的方法跟标识一个tcp连接的方法是一样的，即IP+Port的形式来断定。然后变成 client 的（IP+Port+uid+password)的，也就是Basic Authorization的方式。状态信息可以放在url(GET)，http header(authorizatin, cookie) 或者 post content里面。 对安全性的考虑： 由于每次都携带用户名和密码的这种请求方式极不安全，所以衍生版本就是用cookie来替代每次都携带的用户名和密码，这样就算cookie被人获取利用，也不会泄漏用户名和密码。只有在登陆的时候会传输一次用户名和密码。再者base64是可逆的加密方式，后面也使用不可逆的加密方式如md5（因为它是有损的加密，不可能还原出原密是什么）。但是如果被抓包，还是会被黑客冒名向服务器发出请求。所以早期网上支付等等就需要k宝，动态口令卡之类的东西。现在由于TLS/SSL等技术的出现，http on TLS/SSL 就很安全了。传输层或者socket层之上的信息全部使用密钥加双方证书加密，再靠抓包破解就很难了，所以这几年网络支付又火了起来。 PS: 看了一个wordpress登录的时候是直接POST 明文用户名加密码，好危险。 FAQ: Chrome delete authorization information 在使用 header(‘WWW-Authenticate: Basic realm="userlogin”'); 调试用户登录授权时，浏览器总是会保存之前输入的授权信息。想输入其它用户测试都不行。 所以有两个方法： 1. 使用隐私窗口调试。 2. 在url之前增加 “admin@” 就可以输入新的授权信息了。 php 的header函数，和html 中的标签效果的区别 两个都用来产生response header的，不同的是前者应该直接由服务端在http header里的添加值对。后者只是将值对放在html中传送，由浏览器来解析。这可以在浏览器中调试发现它们的区别。 Session and Cookie Session 是服务端维护的会话信息, cookie是用于标识客户对象和携带客户状态参数的变量。最初由客户端发送，服务端即认识了这个访问对象（可能还要加上ip+port信息），每次客户端有相应的操作之后，服务端即会把一些状态参数加入cookie中返回给客户端。这样服务端就不需保存用户操作状态了。session 保存着这次会话的信息，超时无操作之后就会结束这次会话。 以上纯属个人理解，因为目前在应用层的使用经验比较少，只是在嵌入式开发中涉及到一些初级的简单的应用层开发。属于http的一些最初的实现，只求简单可靠，服务端处理只有C语言。不过也有必要了解一下所谓“未来”的解决方案。有高级的框架的比如 jQuery.