xml地图|网站地图|网站标签 [设为首页] [加入收藏]

正规赌博十大app排名

当前位置:网上十大正规赌博平台 > 正规赌博十大app排名 > 应用中的身份验证技术,浏览器缓存机制浅析

应用中的身份验证技术,浏览器缓存机制浅析

来源:http://www.nb-machinery.com 作者:网上十大正规赌博平台 时间:2019-10-19 03:00

传统 Web 应用中的身份验证技术

2016/12/13 · 基础技术 · WEB, 身份验证

本文作者: 伯乐在线 - ThoughtWorks 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

标题中的 “传统Web应用” 这一说法并没有什么官方定义,只是为了与“现代化Web应用”做比较而自拟的一个概念。所谓“现代化Web应用”指的是那些基于分布式架构思想设计的,面向多个端提供稳定可靠的高可用服务,并且在需要时能够横向扩展的Web应用。相对而言,传统Web应用则主要是直接面向PC用户的Web应用程序,采用单体架构较多,也可能在内部采用SOA的分布式运算技术。

一直以来,传统Web应用为构成互联网发挥了重要作用。因此传统Web应用中的身份验证技术经过几代的发展,已经解决了不少实际问题,并最终沉淀了一些实践模式。

图片 1

在讲述多种身份鉴权技术之前,要强调一点:在构建互联网Web应用过程中,无论使用哪种技术,在传输用户名和密码时,请一定要采用安全连接模式。因为无论采用何种鉴权模型,都无法保护用户凭据在传输过程中不被窃取。

浏览器缓存机制浅析

2015/08/05 · HTML5 · 1 评论 · 缓存

本文作者: 伯乐在线 - 韩子迟 。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

十年WEB技术发展历程

2015/07/19 · HTML5 · WEB

原文出处: 红河小鱼   

一个小分享,知识有限,抛砖引玉。

Basic和Digest鉴权

基于HTTP的Web应用离不开HTTP本身的安全特性中关于身份鉴权的部分。虽然HTTP标准定义了好几种鉴权方式,但真正供Web应用开发者选择的并不多,这里简要回顾一下曾经被广泛运用过的Basic 和 Digest鉴权。

不知道读者是否熟悉一种最直接向服务器提供身份的方式,即在URL中直接写上用户名和密码:

1
2
http://user:passwd@www.server.com/index.html
 

这就是Basic鉴权的一种形式。

Basic和Digest是通过在HTTP请求中直接包含用户名和密码,或者它们的哈希值来向服务器传输用户凭据的方法。Basic鉴权直接在每个请求的头部或URL中包含明文的用户名或密码,或者经过Base64编码过的用户名或密码;而Digest则会使用服务器返回的随机值,对用户名和密码拼装后,使用多次MD5哈希处理后再向服务器传输。服务器在处理每个请求之前,读取收到的凭据,并鉴定用户的身份。

图片 2

Basic和Digest鉴权有一系列的缺陷。它们需要在每个请求中提供凭据,因此提供“记住登录状态”功能的网站中,不得不将用户凭据缓存在浏览器中,增加了用户的安全风险。Basic鉴权基本不对用户名和密码等敏感信息进行预处理,所以只适合于较安全的安全环境,如通过HTTPS安全连接传输,或者局域网。

看起来更安全的Digest在非安全连接传输过程中,也无法抵御中间人通过篡改响应来要求客户端降级为Basic鉴权的攻击。Digest鉴权还有一个缺陷:由于在服务器端需要核对收到的、由客户端经过多次MD5哈希值的合法性,需要使用原始密码做相同的运算,这让服务器无法在存储密码之前对其进行不可逆的加密。Basic 和Digest鉴权的缺陷决定了它们不可能在互联网Web应用中被大量采用。

非HTTP协议定义的缓存机制

浏览器缓存机制,其实主要就是HTTP协议定义的缓存机制(如: Expires; Cache-control等)。但是也有非HTTP协议定义的缓存机制,如使用HTML Meta 标签,Web开发者可以在HTML页面的<head>节点中加入<meta>标签,代码如下:

XHTML

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

1
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">

上述代码的作用是告诉浏览器当前页面不被缓存,每次访问都需要去服务器拉取。使用上很简单,但只有部分浏览器可以支持,而且所有缓存代理服务器都不支持,因为代理不解析HTML内容本身。下面主要介绍HTTP协议定义的缓存机制

ajax

03年的时候我上六年级,那时候网吧刚在小县城的角落萌生。传奇,大话西游第一代网游一时风靡。我抱着试一试的心态给了网吧老板两块钱想申请个号玩玩,然后接下来的一个小时我一直在,注,册,账,号。

彼时网吧用的512k的带宽,注册的时候,填了一堆信息,提交,页面跳转,嘣,”您填写的信息有误,请重填”。然后跳转回注册页面,以此循环。我现在时常想,如果当时ajax能普及开来,我就可以省2块钱了。

那么ajax是什么?

首先ajax是一种技术。以往的网页交互方式,用户在点击一个按钮后,比如提交按钮,用户就要等待漫长的数据和服务器的交互,期间用户无法进行任何操作,只能点根烟。而ajax所做的,就是在向服务器发送请求的时候,我们不必等待结果,而是可以同时做其他的事情,等到有了结果我们可以再来处理这个事

其实ajax技术早在1998年的时候就已经由微软实现了,然而直到2005年2月,Adaptive Path公司的Jesse James Garrett发表文章“Ajax: A New Approach to Web Applications”,人们读了后觉得哎哟不错哦这个屌,这之后ajax才大规模普及开来。

ajax的出现,极大了提高了web的用户体验。时至今日,即使国内IT发展再怎么落后,所有网站的登录注册也已经实现了ajax交互。用户点填写完信息后,页面不用刷新就可以知道信息提交成功与否,哪错改哪。

另外ajax作为一种前后端分离的解决方案,也已经被国内大多数不很low的公司所采用,也间接导致了php等网页脚本语言的衰落。(来辩)

 

简单实用的登录技术

对于互联网Web应用来说,不采用Basic或Digest鉴权的理由主要有两个:

  1. 不能接受在每个请求中发送用户名和密码凭据
  2. 需要在服务器端对密码进行不可逆的加密

因此,互联网Web应用开发已经形成了一个基本的实践模式,能够在服务端对密码强加密之后存储,并且尽量减少鉴权过程中对凭据的传输。其过程如下图所示:

图片 3

这一过程的原理很简单,专门发送一个鉴权请求,只在这个请求头中包含原始用户名和密码凭据,经服务器验证合法之后,由服务器发给一个会话标识(Session ID),客户端将会话标识存储在 Cookie 中,服务器记录会话标识与经过验证的用户的对应关系;后续客户端使用会话标识、而不是原始凭据去与服务器交互,服务器读取到会话标识后从自身的会话存储中读取已在第一个鉴权请求中验证过的用户身份。为了保护用户的原始凭据在传输中的安全,只需要为第一个鉴权请求构建安全连接支持。

服务端的代码包含首次鉴权和后续检查并授权访问的过程:

IUser _user_; if( validateLogin( nameFromReq, pwdFromReq, out _user _)){ Session["CurrentUser"] = _user_; }

1
2
3
4
5
IUser _user_;  
if( validateLogin( nameFromReq, pwdFromReq, out _user _)){  
  Session["CurrentUser"] = _user_;  
}
 

(首次鉴权)

IUser _user_ = Session["CurrentUser"] as IUser; if( _user_ == null ){ Response.Redirect( "/login?return_uri=" Request.Url.ToString() ); return; }

1
2
3
4
5
6
7
IUser _user_ = Session["CurrentUser"] as IUser;  
if( _user_ == null ){  
     Response.Redirect( "/login?return_uri="
     Request.Url.ToString() );  
     return;  
}
 

(后续检查并拒绝未识别的用户)

类似这样的技术简易方便,容易操作,因此大量被运用于很多互联网Web应用中。它在客户端和传输凭据过程中几乎没有做特殊处理,所以在这两个环节尤其要注意对用户凭据的保护。不过,随着我们对系统的要求越来越复杂,这样简易的实现方式也有一些明显的不足。比如,如果不加以封装,很容易出现在服务器应用程序代码中出现大量对用户身份的重复检查、错误的重定向等;不过最明显的问题可能是对服务器会话存储的依赖,服务器程序的会话存储往往在服务器程序重启之后丢失,因此可能会导致用户突然被登出的情况。虽然可以引入单独的会话存储程序来避免这类问题,但引入一个新的中间件就会增加系统的复杂性。

大话浏览器缓存

浏览器缓存一直是一个让人又爱又恨的存在,一方面极大地提升了用户体验,而另一方面有时会因为读取了缓存而展示了“错误”的东西,而在开发过程中千方百计地想把缓存禁掉。如果没听说过浏览器缓存或者不知道浏览器缓存的用处,可以先浏览一下这篇文章->Web缓存的作用与类型 。

那么浏览器缓存机制到底是如何工作的呢?核心就是把缓存的内容保存在了本地,而不用每次都向服务端发送相同的请求,设想下每次都打开相同的页面,而在第一次打开的同时,将下载的js、css、图片等“保存”在了本地,而之后的请求每次都在本地读取,效率是不是高了很多?真正的浏览器工作的时候并不是将完整的内容保存在本地,各种浏览器都有不同的方式,譬如firefox是一种类似innodb的方式存储的key value 的模式,在地址栏中输入 about:cache 可以看见缓存的文件,chrome会把缓存的文件保存在一个叫User Data的文件夹下。但是如果每次都读取缓存也会存在一定的问题,如果服务端的文件更新了呢?这时服务端就会和客户端约定一个有效期,譬如说服务端告诉客户端1天内我服务端的文件不会更新,你就放心地读取缓存吧,于是在这一天里每次遇到相同的请求客户端都开心地可以读取缓存里的文件。但是如果一天过去了,客户端又要读取该文件了,发现和服务端约定的有效期过了,于是就会向服务端发送请求,试图下载一个新的文件,但是很有可能服务端的文件其实并没有更新,其实还是可以读取缓存的。这时该怎么判断服务端的文件有没有更新呢?有两种方式,第一种在上一次服务端告诉客户端约定的有效期的同时,告诉客户端该文件最后修改的时间,当再次试图从服务端下载该文件的时候,check下该文件有没有更新(对比最后修改时间),如果没有,则读取缓存;第二种方式是在上一次服务端告诉客户端约定有效期的同时,同时告诉客户端该文件的版本号,当服务端文件更新的时候,改变版本号,再次发送请求的时候check一下版本号是否一致就行了,如一致,则可直接读取缓存。

而事实上真正的浏览器缓存机制大抵也是如此,接下来就可以分别对号入座了。

需要注意的是,浏览器会在第一次请求完服务器后得到响应,我们可以在服务器中设置这些响应,从而达到在以后的请求中尽量减少甚至不从服务器获取资源的目的。浏览器是依靠请求和响应中的的头信息来控制缓存的

JQUERY

早年的js编程,代码的效率是极其低下的,这点尤其体现在操作dom上,开发者想要给一个按钮添加事件,要写长长一大段重复的代码去获取到这个按钮,再写长长一大段重复的代码去添加事件。尽管老油条会将常用的操作封装起来,但是对于不会封装的新手,这无疑是很痛苦的一件事,尤其再加上各种各样的兼容。

2006年,本着拯救菜鸟,让他们do more的宗旨,jquery诞生。jQuery诞生的意义,一是对ie6 7 8 及各种割据一方的浏览器做好了兼容,二是极大简化了dom操作,使开发效率大大提升。jquery很火爆,火爆的有些前端只会写jquery而不会写原生js的程度。时至今日,说jquery write once,see everywhere已经不为过了。

jquery的另一个意义(我认为)在于,它催化了人们对前端的兴趣与探索,相比linux,你用很低的成本,就可以写出一个让不懂编程的妹子说欧巴你碉堡了的效果,让人们觉得哎哟(又)不错哦这个屌。此后大量的类库和基于jquey的插件雨后春笋般诞生,前端行业歌舞升平欣欣向荣,网页开发进入一个新时代。

 

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

上文提到的简单实用的登录技术已经可以帮助建立对用户身份验证的基本图景,在一些简单的应用场景中已经足够满足需求了。然而,用户鉴权就是有那种“你可以有很多种方法,就是不怎么优雅” 的问题。

最佳实践指的是那些经过了大量验证、被证明有用的方法。而用户鉴权的最佳实践就是使用自包含的、含有加密内容的 Cookie 作为替代凭据。其鉴权过程与上文所提到基于会话标识的技术没有什么区别,而主要区别在于不再颁发会话标识,取而代之的是一个代表身份的、经过加密的 “身份 Cookie”。

图片 4

  1. 只在鉴权请求中发送一次用户名和密码凭据
  2. 成功凭据之后,由服务器生成代表用户身份的 Cookie,发送给客户端
  3. 客户端在后续请求中携带上一步中收到的 “身份 Cookie”
  4. 服务器解密”身份 Cookie”,并对需要访问的资源予以授权

这样,我们消除了对服务器会话存储的依赖,Cookie本身就有有效期的概念,因此顺便能够轻松提供“记住登录状态”的功能。

另外,由于解密Cookie、既而检查用户身份的操作相对繁琐,工程师不得不考虑对其抽取专门的服务,最终采用了面向切面的模式对身份验证的过程进行了封装,而开发时只需要使用一些特性标注(Attribute Annotation)对特定资源予以标记,即可轻松完成身份验证预处理。

Expires与Cache-Control

Expires和Cache-Control就是服务端用来约定和客户端的有效时间的。

图片 5

比如如上一个响应头,Expires规定了缓存失效时间(Date为当前时间),而Cache-Control的max-age规定了缓存有效时间(2552s),理论上这两个值计算出的有效时间应该是相同的(上图好像不一致)。Expires是HTTP1.0的东西,而Cache-Control是HTTP1.1的,规定如果max-age和Expires同时存在,前者优先级高于后者。Cache-Control的参数可以设置很多值,譬如(参考浏览器缓存机制):

图片 6

CHROME

天下武功出谷歌。在ie6,7,8的时代里面,尽管Firefox也缓慢的挑战ie的地位。但和2009年开始Google开始推广的chrome浏览器产生的颠覆性影响比起来,逊色很多。Chrome使用Apple的开源内核webkit,良好的设计标准和市场反应;促进浏览器快速迭代,让IE在windows10中彻底消失。

chrome浏览器的推出,将简化前端的入门程度又推进了一步,其自带的调试工具好用又无脑,我们可以利用其轻松的查看网络状态,加载顺序,进行断点调试等,同时谷歌的插件功能,又给开发者提供了极大便利。

目前chrome最新版开始采用blink内核,测试版本中,已经可以对css3动画进行追踪和调试。在我还没有想象到的时候,chrome已经实现了它。

一句话,没有chrome,就没有新中国,就只能用firefox了。

传统Web应用中的单点登录

单点登录的需求在向用户提供多种服务的企业普遍存在,出发点是希望用户在一个站点中登录之后,在其他兄弟站点中就不需要再次登录。

如果多个子站所在的顶级域名一致,基于上文所述的实践,可以基于Cookie共享实现最简单的单点登录:在多个子站中使用相同的加密、解密配置,并且在用户登录成功后设置身份 Cookie时将domain值设置为顶级域名即可。这样,只要在其中一个网站登录,其身份 Cookie将在用户访问其他子站时也一起带上。不过实际情况中,这个方案的应用场景很有限,毕竟各个子站使用的用户数据模型可能不完全一致,而加密密钥多处共享也增加了服务器应用程序的安全风险。另外,这种方式与“在多个网站中分别存储相同的用户名与密码”的做法相似,可以说是一种“相同的登录”(Same Sign-On),而不是“单点登录”(Single Sign-On)。

对于单点登录需求来说,域名相同与否并不是最大的挑战,集成登录系统对各个子站点的系统在设计上的影响才是。我们希望便利用户的同时,也期待各个子系统仍拥有独立用户身份、独立管理和运维的灵活性。因此我们引入独立的鉴权子站点。

图片 7

当用户到达业务站点A时,被重定向到鉴权站点;登录成功之后,用户被重定向回到业务站点 A、同时附加一个指示“已有用户登录”的令牌串——此时业务站点A使用令牌串,在服务器端从鉴权子站点查询并记录当前已登录的用户。当用户到达业务站点B时,执行相同流程。由于已有用户登录,所以用户登录的过程会被自动省略。

这样的单点登录系统能够较好地解决在多个站点中共享用户登录状态的需求。不过,如果在编程实践过程中略有差池,就会让用户陷入巨大的安全风险中。例如,在上述重定向过程中,一旦鉴权系统未能验证返回URL的合法性,就容易导致用户被钓鱼网站利用。在传统Web应用开发实践中,被广泛部署的身份验证体系是比较重量级的WS-Federation 和 SMAL 等鉴权协议和相对轻量级的 OpenID 等技术。

Last-Modified/If-Modified-Since

而Last-Modified/If-Modified-Since就是上面说的当有效期过后,check服务端文件是否更新的第一种方式,要配合Cache-Control使用。比如第一次访问我的主页simplify the life,会请求一个jquery文件,响应头返回如下信息:

图片 8

然后我在主页按下ctrl r刷新,因为ctrl r会默认跳过max-age和Expires的检验直接去向服务器发送请求(下文再探讨各种刷新后如何读取缓存),我们看看请求截图:

图片 9

请求头中包含了If-Modified-Since项,而它的值和上次请求响应头中的Last-Modified一致,我们发现这个日期是在遥远的2013年,也就是说这个jquery文件自从2013年的那个日期后就没有再被修改过了。将If-Modified-Since的日期和服务端该文件的最后修改日期对比,如果相同,则响应HTTP304,从缓存读数据;如果不相同文件更新了,HTTP200,返回数据,同时通过响应头更新last-Modified的值(以备下次对比)。

GITHUB

随着软件项目的迭代加快,项目版本工具也不断的演进,经历CVS, SVN,GIT。到目前为止CVS差不多已经从互联网行业慢慢消失,SVN作为文件和文档存储存在,由linux内核发明人Linus创建的版本工具GIT现在作为代码版本标准。Github依赖于git成为开发人员团队协作的社区!到2015年1月github上已注册的开发人员超过一千万,开源项目几千万。其中2014中国研发者在github上增⻓长最快。你几乎可以在上面找到一切你想要的代码…比如username..password..

 

本文由网上十大正规赌博平台发布于正规赌博十大app排名,转载请注明出处:应用中的身份验证技术,浏览器缓存机制浅析

关键词:

上一篇:HTML5实现屏幕手势解锁,拖拽上传前传

下一篇:没有了