2017-02技术文章摘要总结

此为2017年2月份看过的技术文章的总结与感悟。

2017-02-13 晴 PM2.5:127 @杭州

99%的人都理解错了HTTP中GET与POST的区别

  • HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议,是数据在万维网中传输的“行为准则”;
  • HTTP中的GETPOST本质上就是TCP连接,是两种不同的传输数据的方式,本质上无差别;
  • 由于浏览器/服务器的对请求处理的限制,GETPOST在应用中体现出一些不同,如GET请求在URL中传送的参数是有长度限制的,而POST则没有;
  • GET请求产生一个数据包:对于GET方式的请求,浏览器会把HTTP header和data一并发送出去,服务器响应200 OK(返回数据);
  • POST产生两个TCP数据包:对于POST方式的请求,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 OK(返回数据)。
    • GET与POST都有自己的语义,不能随便混用;
    • 据研究,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点;
    • 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。

2017-02-16 多云 PM2.5:65 @杭州

登录工程:传统 Web 应用中的身份验证技术

传统Web应用中身份验证最佳实践

  1. 只在鉴权请求中发送一次用户名和密码凭据;
  2. 成功凭据之后,由服务器生成代表用户“身份的 Cookie”(或同时以名值对的形式存储在NoSQL数据库中),发送给客户端;
  3. 客户端在后续请求中携带上一步中收到的 “身份 Cookie”;
  4. 服务器解密”身份 Cookie”(或从NoSQL数据库中获取身份信息),并对需要访问的资源予以授权。

传统Web应用中的单点登录

  • 在便利用户的同时,也期待各个子系统仍拥有独立用户身份、独立管理和运维的灵活性,因此可引入独立的鉴权子站点;
  • 当用户到达业务站点A时,被重定向到鉴权站点;登录成功之后,用户被重定向回到业务站点 A、同时附加一个指示“已有用户登录”的令牌串(token)——此时业务站点A使用令牌串,在服务器端从鉴权子站点查询并记录当前已登录的用户。当用户到达业务站点B时,执行相同流程,由于已有用户登录,所以用户登录的过程会被自动省略。

2017-02-17 阴 PM2.5:80 @杭州

登录工程:现代 Web 应用的典型身份验证需求

  • 我们通常假设用户不信任浏览器,用户通过与服务器建立的临时浏览器会话完成操作。会话开始时,用户被重定向到特定页面进行登录。登录完成后,用户通过持续与服务器交互来延续临时会话的时长;一旦用户一段时间不与服务器交互,则他的会话很快就会过期(被服务器强制登出);
  • 安装在移动设备中的应用程序更受用户信任;登录时将用户重定向到一个网页去登录的做法,并不能提供很好的用户体验——更重要的是,用户在使用移动设备时,时间是碎片化的。我们无法要求用户必须在特定时间内完成操作,也就基本没有会话的概念:我们需要找到一种能够安全地在设备中相对持久地存储用户凭据的方法,并且Web应用服务器可能需要配合这种方式来完成鉴权;
  • 在注册时,越来越多的网站要求用户提供电子邮箱地址或者手机号码,有的网站还支持让用户以多种方式登录。比如,提供一种让用户在使用了一种方式注册之后,还能绑定其他登录方式的功能。绑定完成之后,用户可以选用他喜欢的登录方式。它隐含了一个网站与用户共同的认知:联系方式的拥有者即为用户本人,这种“从属”关系能够用于证实用户的身份。当用户下次在注册新网站时遇到“邮件地址已被注册”,或者“手机号已被注册”的时候,基本可以确定自己曾经注册过这个网站了;
  • 登录过程中所支持的联系方式也呈现出多样性。电子邮件服务在很多场景中逐渐被形式多样的其他联系方式(比如手机、微信等)所取代,不少人根本没有使用邮件的习惯,如果网站只提供邮箱注册的途径,有时候还会遭到那些不经常使用电子邮箱的用户的反感;
  • 上文中提到的“从属”关系不光可以帮助用户判断自己是否注册过一个网站,也可以帮助网站在忘记密码时进行临时认证,从而帮助用户完成新密码的设置。如果将这种从属关系用于正常登录过程中的进一步验证,就构成了双因子鉴权,一种增强型的登录过程;
  • 从整个企业的业务模式(例如网易门户和网易邮箱),到某项业务的具体流程(例如京东订单和京东支付),再到某个流程中的具体步骤(例如短信验证与支付扣款),“服务”这一概念越来越轻量级,于是人们不得不创造了“微服务”这个新的品类词汇来拓展认知空间;
  • 在互联网Web应用中,授权的范畴也包含一个很小的公有部分,是各个业务系统所共有的:即用户状态。我们希望在各业务子系统之间共享用户状态:用户被锁定之后,他在所有业务系统都被锁定;用户被注销之后,所有业务系统中有关他的数据都被封存。另外在多个业务系统中,还可能会共用用户的基本资料和偏好设置等数据。这样,开发一个“用户”系统的想法也就应运而生了。由于与用户的状态等基础信息的关系很紧密,登录与用户系统之间的集成是很自然的,将登录子系统直接作为这个用户系统的一部分也不失为一种不错的实践;
  • 如果识别用户这一需求能够在不需要用户注册的前提下搞定,岂不两全齐美?基于第三方身份提供方的接口来识别已经在其他平台注册的用户,并将其转化为自己应用中的用户,这种方式完全可行。