当前位置:千赢国际官网 > 千赢网页手机版登入 > 登录工程,十年WEB技术发展历程

登录工程,十年WEB技术发展历程

文章作者:千赢网页手机版登入 上传时间:2019-09-29

File杂谈——初识file控件

2015/07/23 · HTML5 · file控件

原文出处: 百码山庄   

首先我说明下,这里介绍的file控件指的是网页中的FileUpload对象,也就是我们常见的<input type=”file”> 。如果你不是想寻找这方面的东西,就可以绕道了。

十年WEB技术发展历程

2015/07/19 · HTML5 · WEB

原文出处: 红河小鱼   

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

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

2017/05/10 · 基础技术 · WEB, 登录

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

“登录工程”的前两篇文章分别介绍了《传统Web应用中的身份验证技术》,以及《现代Web应用中的典型身份验证需求》,接下来是时候介绍适应于现代Web应用中的身份验证实践了。

功能

当我们需要在网页中实现文件上传功能的时候,file控件就可以大显身手了。HTML文档中每添加一个 <input type=”file”> ,实际就是创建了一个FileUpload实例对象。用户可以通过点击file控件选择本地文件,当我们提交包含该file控件的表单时,浏览器会向服务器发送用户选中的本地文件。从而将本地文件传输到服务器,供其他网络用户下载或使用,实现文件上传功能。

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应用”都将对身份的识别看作整个登录的过程,很少出现像企业应用环境中那样复杂的情景和需求。但从之前的文章中我们看到,现代Web应用对身份验证相关的需求已经向复杂化发展了。

我们有必要重新认识一下登录系统。登录指的是从识别用户身份,到允许用户访问其权限相应的资源的过程。举个例子,在网上买好了票之后去影院观影的过程就是一个典型的登录过程:我们先去取票机,输入验证码取票;接着拿到票去影厅检票进入。取票的过程即身份验证,它能够证明我们拥有这张票;而后面检票的过程,则是授权访问的过程。之所以要分成这两个过程,最直接的原因还是业务形态本身具有复杂性——如果观景过程是免费匿名的,也就免去了这些过程。

图片 1

在登录的过程中,“鉴权”与“授权”是两个最关键的过程。接下来要介绍的一些技术和实践,也包含在这两个方面中。虽然现代Web应用的登录需求比较复杂,但只要处理好了鉴权和授权两个方面,其余各个方面的问题也将迎刃而解。在现代Web应用的登录工程实践中,需要结合传统Web应用的典型实践,以及一些新的思路,才能既解决好登录需求,又能符合Web的轻量级架构思路。

美中不足

无可厚非,file控件很强大,给网页上传文件带来了极大的便利。但是,它并非完美!

首先,从控件本身而言,我们可以通过value属性获取到用户选择的文件名称,但出于安全性等因素考虑,该属性无法指定默认值,并且该属性为只读属性。

其次,恐怕也是file控件令很多开发者头疼的地方。file控件在各个主流浏览器之间的表现大有差异,给用户带来的视觉感受大相径庭,而且几乎不可能通过直接修改样式来达到统一,下面我用一张图来更清晰的告诉大家:

图片 2

一目了然了吧?更可恶的是“选择文件”、“Browse…”、“浏览…”三处文字均无法更改!!然而,这仅仅是视觉上的差异,不同浏览器下file控件的行为也存在一些差异:

  • A1、A2、A3、A4、A6,五处我们均可以单击触发文件选择
  • A5 处我们却需要双击才能触发文件选择

总之,file控件从默认视觉效果和交互体验方面来讲,是开发人员和普通用户都很难接受的。

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存在。而在稍微复杂的Web系统中,则需要考虑多种鉴权方式,以及多种授权场景。上一篇文章中所述的“多种登录方式”和“双因子鉴权”就是多种鉴权方式的例子。有经验的人经常调侃说,只要理解了鉴权与授权,就能清晰地理解登录系统了。不光如此,这也是安全登录系统的基础所在。

鉴权的形式丰富多彩,有传统的用户名密码对、客户端证书,有人们越来越熟悉的第三方登录、手机验证,以及新兴的扫码和指纹等方式,它们都能用于对用户的身份进行识别。在成功识别用户之后,在用户访问资源或执行操作之前,我们还需要对用户的操作进行授权。

图片 3

在一些特别简单的情形中——用户一经识别,就可以无限制地访问资源、执行所有操作——系统直接对所有“已登录的人”放行。比如高速公路收费站,只要车辆有合法的号牌即可放行,不需要给驾驶员发一张用于指示“允许行驶的方向或时间”的票据。除了这类特别简单的情形之外,授权更多时候是比较复杂的工作。

在单一的传统Web应用中,授权的过程通常由会话Cookie来完成——只要服务器发现浏览器携带了对应的Cookie,即允许用户访问资源、执行操作。而在浏览器之外,例如在Web API调用、移动应用和富 Web 应用等场景中,要提供安全又不失灵活的授权方式,就需要借助令牌技术。

道高一尺,魔高一丈

既然默认的东西我们都不能接受,那么不能接受的东西我们就要去改变它。

经过无数开发者的不断实践证明,我们不能通过改变宽度,高度,来控制file控件中按钮的尺寸,但是我们可以通过设置file控件的字体大小(font-size)来改变这个按钮的尺寸,更令人可观的是主流浏览器对改变font-size的表现是一致的。

那么,聪明的开发者们就有了应对之策了。

首先,我们从前面表现差异描述中可以发现A2、A4、A6,三处均可单击触发文件选择文件,并且这三处还有一个共同点——它们均处于控件右侧,那么我们就可以改变控件字体大小,让右侧这一部分足够大,并且只让用户看见这一区域(或部分),并且只让用户操作该区域,那么A5处交互效果不一致的问题就可以解决了。为了达到这个目的,我们可以在file控件外面包裹一层容器,并设置尺寸,通过定位将file控件右边区域显示到目标区域,并为容器设置溢出隐藏( overflow: hidden )。我还是用代码来说明吧:

XHTML

<style> .file-group { position: relative; width: 200px; height: 80px; border: 1px solid #ccc; /* 为了显示可见区域,非必须 */ overflow: hidden; } .file-group input { position: absolute; right: 0; top: 0; font-size: 300px; } </style> <div class="file-group"> <input type="file" name="" id="J_File"> </div>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<style>
    .file-group {
        position: relative;
        width: 200px;
        height: 80px;
        border: 1px solid #ccc; /* 为了显示可见区域,非必须 */
        overflow: hidden;
    }
    .file-group input {
        position: absolute;
        right: 0;
        top: 0;
        font-size: 300px;
    }
</style>
<div class="file-group">
    <input type="file" name="" id="J_File">
</div>

在浏览器中查看上面代码的效果,显然Chrome、Firefox、IE下显示效果明显太不一样了(其实文字被放大挤出可见区域了,几乎啥都看不到),那么怎么应对呢?所谓“道高一尺,魔高一丈”,这里简单的原理就是让file控件处于较高的层(z-index),并且设置透明(opacity,低版本IE用filter),让后面的元素来设置样式,以此达到视觉风格统一。说得不是很明白,还是直接上代码吧:

XHTML

<style> .file-group { position: relative; width: 200px; height: 80px; border: 1px solid #ccc; /* 为了显示可见区域,非必须 */ overflow: hidden; cursor: pointer; line-height: 80px; font-size: 16px; text-align: center; color: #fff; background-color: #f50; border-radius: 4px; } .file-group input { position: absolute; right: 0; top: 0; font-size: 300px; opacity: 0; filter: alpha(opacity=0); cursor: pointer; } .file-group:hover { background-color: #f60; } </style> <div class="file-group"> <input type="file" name="" id="J_File"> 选择文件 </div>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<style>
    .file-group {
        position: relative;
        width: 200px;
        height: 80px;
        border: 1px solid #ccc; /* 为了显示可见区域,非必须 */
        overflow: hidden;
        cursor: pointer;
        line-height: 80px;
        font-size: 16px;
        text-align: center;
        color: #fff;
        background-color: #f50;
        border-radius: 4px;
    }
    .file-group input {
        position: absolute;
        right: 0;
        top: 0;
        font-size: 300px;
        opacity: 0;
        filter: alpha(opacity=0);
        cursor: pointer;
    }
    .file-group:hover {
        background-color: #f60;
    }
</style>
<div class="file-group">
    <input type="file" name="" id="J_File">
    选择文件
</div>

最后我们再看下各浏览器表现一致的最终显示效果及交互体验:

图片 4

OK,到这里我们算是对file控件有个简单的认识了,后面我还会提供更多file控件或根据file控件延伸出去的相关资料,有兴趣的朋友可以持续关注。

1 赞 3 收藏 评论

图片 5

CHROME

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

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

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

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

令牌

令牌是一个在各种介绍登录技术的文章中常被提及的概念,也是现代Web应用系统中非常关键的技术。令牌是一个非常简单的概念,它指的是在用户通过身份验证之后,为用户分配的一个临时凭证。在系统内部,各个子系统只需要以统一的方式正确识别和处理这个凭证即可完成对用户的访问和操作进行授权。在上文所提到的例子中,电影票就是一个典型的令牌。影厅门口的工作人员只需要确认来客手持印有对应场次的电影票即视为合法访问,而不需要理会客户是从何种渠道取得了电影票(比如自行购买、朋友赠予等),电影票在本场次范围内可以持续使用(比如可以中场出去休息等)、过期作废。通过电影票这样一个简单的令牌机制,电影票的出售渠道可以丰富多样,检票人员的工作却仍然简单轻松。

图片 6

从这个例子也可以看出令牌并非什么神奇的机制,只是一种很常见的做法。还记得第一篇文章中所述的“自包含的Cookie”吗?那实际上就是一个令牌而已,而且在令牌中写有关于有效性的内容——正如一个电影票上会写明场次与影厅编号一样。可见,在Web安全系统中引入令牌的做法,有着与传统场合一样的妙用。在安全系统中,令牌经常用于包含安全上下文信息,例如被识别的用户信息、令牌的颁发来源、令牌本身的有效期等。另外,在必要时可以由系统废止令牌,在它下次被使用用于访问、操作时,用户被禁止。

由于令牌有这些特殊的妙用,因此安全行业对令牌标准的制定工作一直没有停止过。在现代化Web系统的演进过程中,流行的方式是选用基于Web技术的“简单”的技术来代替相对复杂、重量级的技术。典型地,比如使用JSON-RPC或REST接口代替了SOAP格式的服务调用,用微服务架构代替了SOA架构等等。而适用于Web技术的令牌标准就是Json Web Token(JWT),它规范了一种基于JSON的令牌的简单格式,可用于安全地封装安全上下文信息。

GITHUB

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

 

OAuth 2、Open ID Connect

令牌在广为使用的OAuth技术中被采用来完成授权的过程。OAuth是一种开放的授权模型,它规定了一种供资源拥有方与消费方之间简单又直观的交互方法,即从消费方向资源拥有方发起使用AccessToken(访问令牌)签名的HTTP请求。这种方式让消费方应用在无需(也无法)获得用户凭据的情况下,只要用户完成鉴权过程并同意消费方以自己的身份调用数据和操作,消费方就可以获得能够完成功能的访问令牌。OAuth简单的流程和自由的编程模型让它很好地满足了开放平台场景中授权第三方应用使用用户数据的需求。不少互联网公司建设开放平台,将它们的用户在其平台上的数据以 API 的形式开放给第三方应用来使用,从而让用户享受更丰富的服务。

图片 7

OAuth在各个开放平台的成功使用,令更多开发者了解到它,并被它简单明确的流程所吸引。此外,OAuth协议规定的是授权模型,并不规定访问令牌的数据格式,也不限制在整个登录过程中需要使用的鉴权方法。人们很快发现,只要对OAuth进行合适的利用即可将其用于各种自有系统中的场景。例如,将 Web 服务视作资源拥有方,而将富Web应用或者移动应用视作消费方应用,就与开放平台的场景完全吻合。

另一个大量实践的场景是基于OAuth的单点登录。OAuth并没有对鉴权的部分做规定,也不要求在握手交互过程中包含用户的身份信息,因此它并不适合作为单点登录系统来使用。然而,由于OAuth的流程中隐含了鉴权的步骤,因而仍然有不少开发者将这一鉴权的步骤用作单点登录系统,这也俨然衍生成为一种实践模式。更有人将这个实践进行了标准化,它就是Open ID Connect——基于OAuth的身份上下文协议,通过它即可以JWT的形式安全地在多个应用中共享用户身份。接下来,只要让鉴权服务器支持较长的会话时间,就可以利用OAuth为多个业务系统提供单点登录功能了。

图片 8

我们还没有讨论OAuth对鉴权系统的影响。实际上,OAuth对鉴权系统没有影响,在它的框架内,只是假设已经存在了一种可用于识别用户的有效机制,而这种机制具体是怎么工作的,OAuth并不关心。因此我们既可以使用用户名密码(大多数开放平台提供商都是这种方式),也可以使用扫码登录来识别用户,更可以提供诸如“记住密码”,或者双因子验证等其他功能。

本文由千赢国际官网发布于千赢网页手机版登入,转载请注明出处:登录工程,十年WEB技术发展历程

关键词: 千赢国际官网