无数佧白天，现实被支离破碎的演绎，泛泛消褪，灿烂的锋艺。

        手握一杯醇醇的咖啡，坐在教室的角落的空前，默默地望着窗外的风景，思绪一点一点蔓延。想起《玻璃杯》里一句歌词：我又说我是一只玻璃杯，心痛的无言以对。就算是再洒脱笑得再美，心碎了要用什么来赔。多一佔爱就多一点疲惫，洒掉一些让自己放飞。让自己放飞？如何飞？脸上掠过一丝苦涩的笑容，一如手中咖啡的味道。啜一口，审视自己的平静，外界喧闹瞬间蒸发。岁月刹那间停刹。只静静的让灵魂自由的游走，品味成长的历程。

          我用潇洒伪装自己，用冷静和故作的成熟掩盖心痛。阳光洒满大地。地唯独照不亮心中那片小小的天地。渴望平静，却平静的让人寂寞，寂寞又来的如此可怕。真怕在这寂寞中将自己沦落。昔日的激情和壮志被吞噬，时间的脚步也似乎永远定格在这刻，压抑、崩溃、窒息。无法忍受，要努力将这一切打破！

          不甘就这样在静默中死亡，真想为阳光着色，来驱除心中的阴霾。远离落寞，背上行囊，继续昂首阔步走向梦想的远方。所有的苦闷，所有的彷徨，轻轻退到一旁，给我自己的方向。不再辜负年华韶光，直达梦的天堂！成长的路上，我们需要坚强，光阴不觉，我们已悄然长大；韶华飞逝，我们已成为别人的肩膀。

          每个人生命中不可避免的总有些忧郁彷徨纠缠着，无论哪个阶段，迷茫你前进的方向；不安现状的人总会为生活的平庸自寻烦恼，于是去追求、奋斗，碰壁再碰壁。当失败成为常态，雄心沦为无奈，整日的奔波奋斗却换来无起色的未来。这样的生活又有几人能坚持得下来？平庸的人生就是在反复的失败中放弃自己。

       世界可以无奈，你却不能对生活撒娇耍赖。只有破罐才会破摔。天地无情，不会因你的弱小而对你备加表睐。要让世界知道你的存在，就必须从苦闷中彰显气概。尽情挥洒你的精彩。每个人都是磁场，放弃招来随落，坚持吸引希望。试问，谁不曾为未来迷惘？

      因为年轻，所以要自信。心系梦想，我心才会飞扬！赋予自己腾飞的翅膀，去远方自由闯荡。成长的路上，任你自由徜徉，不灭的永远是希望！谪仙李白曾经告诉我们；长风破浪会有时，直挂云帆济沧海。不妨循着古迹，站在前人的肩膀，让梦启航－－－乘千里长风，破万里巨浪，直抵成功的远方！

Request.ServerVariables("Path_Info")
客户端提供的路径信息

Request.ServerVariables("Appl_Physical_Path")
与应用程序元数据库路径相应的物理路径

Request.ServerVariables("Path_Translated")
通过由虚拟至物理的映射后得到的路径
Request.ServerVariables("Script_Name")
执行脚本的名称

Request.ServerVariables("Query_String")
查询字符串內容

Request.ServerVariables("Http_Referer")
请求的字符串內容

Request.ServerVariables("Server_Port")
接受请求的服务器端口号

Request.ServerVariables("Remote_Addr")
发出请求的远程主机的IP地址

Request.ServerVariables("Remote_Host")
发出请求的远程主机名称

Request.ServerVariables("Local_Addr")
返回接受请求的服务器地址

Request.ServerVariables("Http_Host")
返回服务器地址

Request.ServerVariables("Server_Name")
服务器的主机名、DNS地址或IP地址

Request.ServerVariables("Request_Method")
提出请求的方法比如GET、HEAD、POST等等

Request.ServerVariables("Server_Port_Secure")
如果接受请求的服务器端口为安全端口时，则为1，否则为0

Request.ServerVariables("Server_Protocol")
服务器使用的协议的名称和版本

Request.ServerVariables("Server_Software")
应答请求并运行网关的服务器软件的名称和版本

Request.ServerVariables("All_Http")
客户端发送的所有HTTP标头，前缀HTTP_

Request.ServerVariables("All_Raw")
客户端发送的所有HTTP标头,其结果和客户端发送时一样，没有前缀HTTP_

Request.ServerVariables("Appl_MD_Path")
应用程序的元数据库路径

Request.ServerVariables("Content_Length")
客户端发出內容的长度

Request.ServerVariables("Https")
如果请求穿过安全通道（SSL），则返回ON如果请求来自非安全通道，则返回OFF

Request.ServerVariables("Instance_ID")
IIS实例的ID号

Request.ServerVariables("Instance_Meta_Path")
响应请求的IIS实例的元数据库路径

Request.ServerVariables("Http_Accept_Encoding")
返回內容如：gzip,deflate

Request.ServerVariables("Http_Accept_Language")
返回內容如：en-us

Request.ServerVariables("Http_Connection")
返回內容：Keep-Alive

Request.ServerVariables("Http_Cookie")

Request.ServerVariables("Http_User_Agent")
返回內容：Mozilla/4.0(compatible;MSIE6.0;WindowsNT5.1;SV1)

Request.ServerVariables("Https_Keysize")
安全套接字层连接关键字的位数，如128

Request.ServerVariables("Https_Secretkeysize")
服务器验证私人关键字的位数如1024

Request.ServerVariables("Https_Server_Issuer")
服务器证书的发行者字段

Request.ServerVariables("Https_Server_Subject")
服务器证书的主题字段

Request.ServerVariables("Auth_Password")
当使用基本验证模式时，客户在密码对话框中输入的密码

Request.ServerVariables("Auth_Type")
是用户访问受保护的脚本时，服务器用於检验用户的验证方法

Request.ServerVariables("Auth_User")
代证的用户名

Request.ServerVariables("Cert_Cookie")
唯一的客户证书ID号

Request.ServerVariables("Cert_Flag")
客户证书标誌，如有客户端证书，则bit0为0如果客户端证书验证无效，bit1被设置为1

Request.ServerVariables("Cert_Issuer")
用户证书中的发行者字段

Request.ServerVariables("Cert_Keysize")
安全套接字层连接关键字的位数，如128

Request.ServerVariables("Cert_Secretkeysize")
服务器验证私人关键字的位数如1024

Request.ServerVariables("Cert_Serialnumber")
客户证书的序列号字段

Request.ServerVariables("Cert_Server_Issuer")
服务器证书的发行者字段

Request.ServerVariables("Cert_Server_Subject")
服务器证书的主题字段

Request.ServerVariables("Cert_Subject")
客户端证书的主题字段

Request.ServerVariables("Content_Type")
客户发送的form內容或HTTPPUT的数据类型

第一大当：买房 

　  买房意味着什么？意味着你拥有了一个属于自己的房子。是的，你是这样以为，但是在中国你并无法拥有这个房子，只是租给你而已。因为房子是你的,地不是你的,只是把土地使用权70年(从现在退70年那是抗日战争时期,谁见过那时候的房子?)。房子通常情况下30年左右就会遇上拆迁或者旧房改造。也就是说你花了买房的钱，却只能得到租房的实际效果。当然这还不是最坏的。最坏的是，当几十年后你发觉上当了！有一群流氓冲进你用一辈子积蓄买下的房子，画上一个大大的拆字！然后把你的家当全部当垃圾一样的仍出门外，不顾你的苦苦哀求，甚至还在报纸上给你按一个钉子户的臭名，任大众辱骂的时候你就会知道什么叫做绝望！ 

　　形容中国的房地产有一个很有名的笑话是这样写的： 

　　以前，有个地主有很多地，找了很多长工干活，地主给长工们盖了一批团结楼住着，一天，地主的谋士对地主说：东家，长工们这几年手上有点钱了，他们住你的房子，每月交租子，不划算，反正他们永远住下去，你干脆把房子卖给他们起个名堂叫做——公房出售！告诉他们房子永远归他们了，可以把他们这几年攒的钱收回来，地主说：不错，那租金怎么办？谋士说：照收不误，起个日本名儿，叫物业费！地主很快实行了，赚了好多钱，长工们那个高兴啊！ 

　　过了几年，地主的村子发展成城镇了，有钱人越来越多，没地方住，谋士对地主说：东家，长工们这几年手上又有钱了，咱们给他们盖新房子，起个名堂叫做旧城改造，他们把手上的钱给我们，我们拆了房子盖新的，叫他们再买回去，可以多盖一些卖给别人，地主又实行了，这次，有些长工们不高兴了，地主的家丁派上用途了，长工们打掉牙只好往肚子里咽，地主又赚了好多钱。

    又过了几年，地主的村子发展成大城市了，有钱人更多了，地主的土地更值钱了，谋士对地主说：东家，咱们把这些长工的房子拆了，在这个地方建别墅，拆出来的地盖好房子卖给那些有钱的大款还能赚一笔，地主说：长工们不干怎么办？谋士说：咱给他们钱多点儿，起个名堂叫货币化安置，咱再到咱们的猪圈旁边建房子，起个名堂叫经济适用房，给他们修个马车道让他们到那边买房住，地主说：他们钱不够怎么办？谋士说：从咱家的钱庄借前给他们，一年6分利，咱这钱还能生钱崽，又没风险，地主又实行了，长工们拿到钱，地主的经济适用房到现在才建了一间，长工们只好排队等房子，直到现在，还等着呢……

　　于是，长工们开始闹事了，地主有点慌，忙问谋士怎么办？谋士说：赶紧通知长工们，房子要跌价了，别买了，租房住吧，正好把我们的猪圈租给他们，结果，这么多年后，长工们的钱全没了，还在租房住，直到永远！ 

　　这个笑话虽然有点夸张，但实际上这何尝又不是事实呢？有人说既然如此？为什么中国人还要买房？疯了一样的买？为什么？还不是愚民教育的结果，就好象60 年代，鼓吹人们必须购买三大件：手表、缝纫机、自行车才算是成功人士才可嫁人娶妻。70年代鼓吹人们必须购买新四大件：电视，冰箱，洗衣机，装电话才算是出人头地才可娶妻生子一样，记得当年装电话可是要几千块钱一部啊（人均收入不到200的小城），而北京上海更有上万一部的时候，还得排队买号搭人情，和今天的买房又何其相似？

而今天所有的狗屁学者又开始了这一套愚弄百姓的旧招：白领一族新标准，成功人士新选择X环X路小户型，X环X路商住型。收了你几十万后，还得每个月收你租金（新物业费），银行利息，以及各种巧立名目的加息、政策等等。总之不怕你不被整死，就怕你死得不够惨！老百姓咋就怎么乐于上当，而且百上不厌呢？我真是气得浑身都湿了！

 点评：看清教育的现实，被教育了这多么年了，什么时候教你怎么去赚钱了，都是在教你怎么给别人赚钱。为什么会有愚民教育，没有SB 哪能有聪明人呢 

我们要基于以下认识：
（1）Control的Invoke和BeginInvoke与Delegate的Invoke和BeginInvoke是不同的。
（2）Control的Invoke和BeginInvoke的参数为delegate，委托的方法是在Control的线程上执行的，也就是我们平时所说的UI线程。

我们以代码(一)来看(Control的Invoke)
private delegate void InvokeDelegate();
private void InvokeMethod(){
   //C代码段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A代码段.......
   this.Invoke(new InvokeDelegate(InvokeMethod));
   //B代码段......
}
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------>C---------------->B
解释：(1)A在UI线程上执行完后，开始Invoke，Invoke是同步
(2)代码段B并不执行，而是立即在UI线程上执行InvokeMethod方法，即代码段C。
(3)InvokeMethod方法执行完后，代码段C才在UI线程上继续执行。

看看代码(二)，Control的BeginInvoke
private delegate void BeginInvokeDelegate();
private void BeginInvokeMethod(){
   //C代码段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A代码段.......
   this.BeginInvoke(new BeginInvokeDelegate(BeginInvokeMethod));
   //B代码段......
}
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A----------->B--------------->C慎重，这个只做参考。。。。。，我也不肯定执行顺序，如果有哪位达人知道的话请告知。
解释：：(1)A在UI线程上执行完后，开始BeginInvoke，BeginInvoke是异步
(2)InvokeMethod方法，即代码段C不会执行，而是立即在UI线程上执行代码段B。
(3)代码段B执行完后(就是说butBeginInvoke_Click方法执行完后)，InvokeMethod方法，即代码段C才在UI线程上继续执行。

由此，我们知道：
Control的Invoke和BeginInvoke的委托方法是在主线程，即UI线程上执行的。也就是说如果你的委托方法用来取花费时间长的数据，然后更新界面什么的，千万别在UI线程上调用Control.Invoke和Control.BeginInvoke，因为这些是依然阻塞UI线程的，造成界面的假死。

那么，这个异步到底是什么意思呢?

异步是指相对于调用BeginInvoke的线程异步，而不是相对于UI线程异步，你在UI线程上调用BeginInvoke ，当然不行了。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。
BeginInvoke的原理是将调用的方法Marshal成消息，然后调用Win32 API中的RegisterWindowMessage()向UI窗口发送消息。－－－－摘自"Invoke和BeginInvoke的真正涵义"一文中的评论。

(二)我们用Thread来调用BeginInvoke和Invoke
      我们开一个线程，让线程执行一些耗费时间的操作，然后再用Control.Invoke和Control.BeginInvoke回到用户UI线程，执行界面更新。

 代码(三)  Thread调用Control的Invoke

private Thread invokeThread;
private delegate void invokeDelegate();
private void StartMethod(){
   //C代码段......
   Control.Invoke(new invokeDelegate(invokeMethod));
  //D代码段......
}
private void invokeMethod(){
  //E代码段
}
private void butInvoke_Click(object sender, EventArgs e) {
   //A代码段.......
   invokeThread = new Thread(new ThreadStart(StartMethod));
   invokeThread.Start();
   //B代码段......
}
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A------>(Start一开始B和StartMethod的C就同时执行)---->(C执行完了，不管B有没有执行完，invokeThread把消息封送(invoke)给UI线程，然后自己等待)---->UI线程处理完butInvoke_Click消息后，处理invokeThread封送过来的消息，执行invokeMethod方法，即代码段E，处理往后UI线程切换到invokeThread线程。
这个Control.Invoke是相对于invokeThread线程同步的，阻止了其运行。

解释：
1。UI执行A
2。UI开线程InvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程invokeThread上。
3。invokeThread封送消息给UI，然后自己等待，UI处理完消息后，处理invokeThread封送的消息，即代码段E
4。UI执行完E后，转到线程invokeThread上，invokeThread线程执行代码段D

代码(四)  Thread调用Control的BeginInvoke
private Thread beginInvokeThread;
private delegate void beginInvokeDelegate();
private void StartMethod(){
   //C代码段......
   Control.BeginInvoke(new beginInvokeDelegate(beginInvokeMethod));
  //D代码段......
}
private void beginInvokeMethod(){
  //E代码段
}
private void butBeginInvoke_Click(object sender, EventArgs e) {
   //A代码段.......
   beginInvokeThread = new Thread(new ThreadStart(StartMethod));
   beginInvokeThread .Start();
   //B代码段......
}
你觉得代码的执行顺序是什么呢?记好Control的Invoke和BeginInvoke都执行在主线程即UI线程上
A在UI线程上执行----->beginInvokeThread线程开始执行，UI继续执行代码段B，并发地invokeThread执行代码段C-------------->不管UI有没有执行完代码段B，这时beginInvokeThread线程把消息封送给UI，单自己并不等待，继续向下执行-------->UI处理完butBeginInvoke_Click消息后，处理beginInvokeThread线程封送过来的消息。

解释：
1。UI执行A
2。UI开线程beginInvokeThread，B和C同时执行，B执行在线程UI上，C执行在线程beginInvokeThread上。
3。beginInvokeThread封送消息给UI，然后自己继续执行代码D，UI处理完消息后，处理invokeThread封送的消息，即代码段E
有点疑问：如果UI先执行完毕，是不是有可能过了段时间beginInvokeThread才把消息封送给UI，然后UI才继续执行封送的消息E。如图浅绿的部分。


Control的BeginInvoke是相对于调用它的线程，即beginInvokeThread相对是异步的。
因此，我们可以想到。如果要异步取耗费长时间的数据，比如从数据库中读大量数据，我们应该这么做。
(1)如果你想阻止调用线程，那么调用代码(三)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的方法。
(2)如果你不想阻止调用线程，那么调用代码(四)，代码段D删掉，C改为耗费长时间的操作，因为这个操作是在另外一个线程中做的。代码段E改为更新界面的方法。

       今天在博客园看了《程序员：挑战无处不在》谷哥明白了为什么我会在一个简单的用户登陆上浪费时间,以前我们写的哪些程序哪还叫程序吗？ 如果只是给客户来开发一个东西出来在不考虑效率的情况下，以.net 本身的优势，可以在很短的时间就能完成。谷哥是在给自己开发程序，所以有做到最好。在登陆的地方有什么是值得思考的呢？怎样写一个好的用户登录功能

　　用户名和口令

　　首先，我们先来说说用户名和口令的事。这并不是本站第一次谈论这个事了。如何管理自己的口令让你知道怎么管理自己的口令，破解你的口令让你知道在现代这样速度的计算速度下，用穷举法破解你的口令可能会是一件很轻松的事。在这里我想告诉从开发者的角度上来做设计这个用户名和口令的事。下面一几件规则：

限制用户输入一些非常容易被破解的口令。如什么qwert，123456, password之类，就像twitter限制用户的口令一样做一个口令的黑名单。另外，你可以限制用户口令的长度，是否有大小写，是否有数字，你可以用你的程序做一下校验。当然，这可能会让用户感到很不爽，所以，现在很多网站都提供了UX让用户知道他的口令强度是什么样的（比如这个有趣的UX），这样可以让用户有一个选择，目的就是告诉用户——要想安全，先把口令设得好一点。

千万不要明文保存用户的口令。正如如何管理自己的口令所说的一样，很多时候，用户都会用相同的ID相同的口令来登录很多网站。所以，如果你的网站明文保存的话，那么，如果你的数据被你的不良员工流传出去那对用户是灾难性的。所以，用户的口令一定要加密保存，最好是用不可逆的加密，如MD5或是SHA1之类的有hash算法的不可逆的加密算法。CSDN曾明文保存过用户的口令。（另，对于国内公司的品行以及有关部门的管理方式，我不敢保证国内网站以加密的方式保存你的口令。我觉得，做为一个有良知的人，我们应该加密保存用户的口令）

是否让浏览器保存口令。我们有N多的方法可以不让浏览器保存用户名和口令。但是这可能对用户来说很不爽。因为在真实世界里谁也记得不住那么多的口令。很多用户可能会使用一些密码管理工具来保存密码，浏览器只是其中一种。是否让浏览器保存这个需要你做决定，重点是看一下你的系统的安全级别是否要求比较高，如果是的话，则不要让浏览器保存密码，并在网站明显的位置告诉用户——保存口令最安全的地方只有你的大脑。

口令在网上的传输。因为HTTP是明文协议，所以，用户名和口令在网上也是明文发送的，这个很不安全。你可以看看这篇文章你就明白了。要做到加密传输就必需使用HTTPS协议。但是，在中国还是有很多网站的Web登录方式还在使用ActiveX控件，这可能成为IE6还大量存在的原因。我通常理解为这些ActiveX控件是为了反键盘记录程序的。不过，我依然觉ActiveX控件不应该存在，因为在国外的众多安全很重要的站点上都看不到ActiveX的控件的身影。

　　用户登录状态

　　首先，我想告诉大家的是，因为HTTP是无状态的协议，也就是说，这个协议是无法记录用户访问状态的，其每次请求都是独立的无关联的，一笔是一笔。而我们的网站都是设计成多个页面的，所在页面跳转过程中我们需要知道用户的状态，尤其是用户登录的状态，这样我们在页面跳转后我们才知道是否可以让用户有权限来操作一些功能或是查看一些数据。

　　所以，我们每个页面都需要对用户的身份进行认证。当然，我们不可能让用户在每个页面上输入用户名和口令，这会让用户觉得我们的网站相当的SB。为了实现这一功能，用得最多的技术就是浏览器的cookie，我们会把用户登录的信息存放在客户端的cookie里，这样，我们每个页面都从这个cookie里获得用户是否登录的信息，从而达到记录状态，验证用户的目的。但是，你真的会用cookie吗？下面是使用cookie的一些原则。

千万不要在cookie中存放用户的密码。加密的密码都不行。因为这个密码可以被人获取并尝试离线穷举。所以，你一定不能把用户的密码保存在cookie中。我看到太多的站点这么干了。

正确设计“记住密码”。这个功能简直就是一个安全隐患，我觉得并不是所有的程序员都知道怎么设计这个事。一般的设计是——一时用户勾选了这个功能，系统会生成一个cookie，cookie包括用户名和一个固定的散列值，这个固定的散列值一直使用。这样，你就可以在所有的设备和客户上都可以登录，而且可以有多个用户同时登录。这个并不是很安全。下面是一些更为安全的方法供你参考：

（——更新 2011/08/26，原文中有些小错误，并且说的不清楚，重新调整了一下——）

　　1）在cookie中，保存三个东西——用户名，登录序列，登录token。

　　用户名：明文存放。

　　登录序列：一个被MD5散列过的随机数，仅当强制用户输入口令时更新（如：用户修改了口令）。

　　登录token：一个被MD5散列过的随机数，仅一个登录session内有效，新的登录session会更新它。

　　2）上述三个东西会存在服务器上，服务器的验证用户需要验证客户端cookie里的这三个事。

　　3）这样的设计会有什么样的效果，会有下面的效果，

　　　　a）登录token是单实例登录。意思就是一个用户只能有一个登录实例。

　　　　b）登录序列是用来做盗用行为检测的。如果用户的cookie被盗后，盗用者使用这个cookie访问网站时，我们的系统是以为是合法用户，然后更新“登录token”，而真正的用户回来访问时，系统发现只有“用户名”和“登录序列”相同，但是“登录token”不对，这样的话，系统就知道，这个用户可能出现了被盗用的情况，于是，系统可以清除并更改登录序列 和 登录token，这样就可以令所有的cookie失效，并要求用户输入口令。并给警告用户系统安全。

　　4）当然，上述这样的设计还是会有一些问题，比如：同一用户的不同设备登录，甚至在同一个设备上使用不同的浏览器保登录。一个设备会让另一个设备的登录token和登录序列失效，从而让其它设备和浏览器需要重新登录，并会造成cookie被盗用的假象。所以，你在服务器服还需要考虑- IP 地址，

　　　　a）如果以口令方式登录，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为口令只有真正的用户知道。

　　　　b）如果 IP相同 ，那么，我们无需更新服务器的“登录序列”和 “登录token”（但需要更新cookie）。因为我们认为是同一用户有同一IP（当然，同一个局域网里也有同一IP，但我们认为这个局域网是用户可以控制的。网吧内并不推荐使用这一功能）。

　　　　c）如果（IP不同 &&没有用口令登录），那么，“登录token”就会在多个IP间发生变化（登录token在两个或多个ip间被来来回回的变换），当在一定时间内达到一定次数后，系统才会真正觉得被盗用的可能性很高，此时系统在后台清除“登录序列”和“登录token“，让Cookie失效，强制用户输入口令（或是要求用户更改口令），以保证多台设备上的cookie一致。

不要让cookie有权限访问所有的操作。否则就是XSS攻击，这个功能请参看新浪微博的XSS攻击。下面的这些功能一定要用户输入口令：

　　1）修改口令。

　　2）修改电子邮件。（电子邮件通过用来找回用户密码）

　　3）用户的隐私信息。

　　4）用户消费功能。

权衡Cookie的过期时间。如果是永不过期，会有很不错的用户体验，但是这也会让用户很快就忘了登录密码。如果设置上过期期限，比如2周，一个月，那么可能会好一点，但是2周和一个月后，用户依然会忘了密码。尤其是用户在一些公共电脑上，如果保存了永久cookie的话，等于泄露了帐号。所以，对于cookie的过期时间我们还需要权衡。

　　找回口令的功能

　　找回口令的功能一定要提供。但是很多朋友并不知道怎么来设计这个功能。我们有很多找回口令的设计，下面我逐个点评一下。

千万不要使用安全问答。事实证明，这个环节很烦人，而且用户并不能很好的设置安全问答。什么，我的生日啊，我母亲的生日，等等。因为今天的互联网和以前不一样了，因为SNS，今天的互联比以前更真实了，我可以上facebook，开心，人人网，LinkedIn查到你的很多的真实的信息。通过这些信息我可以使用安全问答来重设你的口令。这里需要说一下 Facebook，Facebook的安全问答很强大，还要你通过照片认人，呵呵。

不要重置用户的密码。因为这有可能让用户的密码遭到恶意攻击。当然，你要发个邮件给用户让其确认，用户点击邮件中的一个链接，你再重置。我并不推荐这样的方法，因为用户一般都会用笔记下来这个很难记的口令，然后登录系统，因为登录系统时使用了“记住密码”的功能，所以导致用户不会去修改密码，从而要么导到被写下来的密码被人盗取，要么又忘记了密码。

好一点的做法——通过邮件自行重置。当用户申请找回口令功能的时候，系统生成一个MD5唯一的随机字串（可通过UID+IP+timestamp+随机数），放在数据库中，然后设置上时限（比如1小时内），给用户发一个邮件，这个连接中包含那个MD5的字串的链接，用户通过点击那个链接来自己重新设置新的口令。

更好一点的做法——多重认证。比如：通过手机+邮件的方式让用户输入验证码。手机+邮件可能还不把握，因为手机要能会丢了，而我的手机可以访问我的邮箱。所以，使用U盾，SecureID（一个会变化的6位数token），或是通过人工的方式核实用户身份。当然，这主要看你的系统的安全级别了。

　　口令探测防守

使用验证码。验证码是后台随机产生的一个短暂的验证码，这个验证码一般是一个计算机很难识别的图片。这样就可以防止以程序的方式来尝试用户的口令。事实证明，这是最简单也最有效的方式。当然，总是让用户输入那些肉眼都看不清的验证码的用户体验不好，所以，可以折中一下。比如Google，当他发现一个IP地址发出大量的搜索后，其会要求你输入验证码。当他发现同一个IP注册了3个以上的gmail邮箱后，他需要给你发短信方式或是电话方式的验证码。

用户口令失败次数。调置口令失败的上限，如果失败过多，则把帐号锁了，需要用户以找回口令的方式来重新激活帐号。但是，这个功能可能会被恶意人使用。最好的方法是，增加其尝试的时间成本（以前的这篇文章说过一个增加时间成本的解密算法）。如，两次口令尝试的间隔是5秒钟。三次以上错误，帐号被临时锁上30秒，5次以上帐号被锁1分钟，10次以上错误帐号被锁4小时……

系统全局防守。上述的防守只针对某一个别用户。恶意者们深知这一点，所以，他们一般会动用“僵尸网络”轮着尝试一堆用户的口令，所以上述的那种方法可能还不够好。我们需要在系统全局域上监控所有的口令失败的次数。当然，这个需要我们平时没有受到攻击时的数据做为支持。比如你的系统，平均每天有5000次的口令错误的事件，那么你可以认为，当口令错误大幅超过这个数后，而且时间相对集中，就说明有黑客攻击。这个时候你怎么办？一般最常见使用的方法是让所有的用户输错口令后再次尝试的时间成本增加。

　　最后，再说一下，关于用户登录，使用第三方的 OAuth 和 OpenID 也不失为一个很不错的选择。

         程序员要的是相思， 要的是分析问题的能力，有好多的问题在目前看来都不是哪么的合理。技术是需要改变的，在不同的时期，当你觉得昨天你的code 不是哪么的完美，哪么你就进步了。

 一、网页设计相关：