在专业的 Web 站台上，常常会需要使用者的帐号及密码，也就是身份确认的动作。早期的 NCSA httpd 伺服器并没有提供这项使用者确认的功能，Webmaster 只能用手工打造一个身份确认的 CGI 程式。
自 CERN httpd 之后的 Web 伺服器大部份都提供了使用者身份确认的功能。仅管每套 Web 伺服器的设定都不太相同，但在设定上都大同小异。
以下就是 Apache 伺服器上的使用者身份确认的设定。
<Directory /home/MyMember>
AuthType Basic
AuthName MyMember
AuthUserFile /usr/local/MyMember.txt
Options Includes ExecCGI
<Limit GET POST>
require valid-user
</Limit>
</Directory>
在这个例子中，当使用者在看 MyMember 目录下所有的档案，包括图片档案及其它各式档案时，都需要使用者的帐号密码确认。而使用者的帐号及密码档都存在于/usr/local/MyMember.txt 之中。
这个帐号密码档 /usr/local/MyMember.txt 的样子可能如下例。其中冒号前的字串是使用者帐号，冒号之后的字串是经过不可还原加密的密码，编码一般都是使用传统的 DES 编码，密码的头二个字是类似种子的字元 (salt)，本例中都是 3P。每行代表一位使用者。当然 Webmaster 要自行控制重覆帐号的情形。比较特殊是在 Win32 系统上架 Apache 的情形，冒号后的密码不可加密，因为 Win32 没有提供这方面的编码
API，因此使用者密码以明码的方式存在。
john1234:3PWudBlJMiwro
queenwan:3PFNVLNPN9W0M
noname00:3PEsXaJx5pk7E
wilson49:3PjoWb0EnaG22
rootboot:3PIt0snI6.84E
sun_moon:3PvymMeNOc.x.
nobody38:3PbskPKwV94hw
在 Apache 1.3.6 版上，可以用 ~apache/bin/htpasswd 来产生单笔的帐号及密码，但对于需要大笔资料的商业站台，可能就需要自行写程式来处理了。UNIX 上需要呼叫 crypt() 来处理编码。
在一切都设定好了之后，连线时就会在浏览器出现查核密码的视窗，如上图就是SEEDNet 的 MySEED 网站的使用者查核机制。在输入了帐号及密码后，浏览器会将它用BASE64 编码后，传到伺服器端。当然 BASE64 只是编码不是加密，因此在网路上这种传输的安全性仍然不高，还是有可能被中间的刽客截下，再将 BASE64 还原，这也是整个使用者认证中最美中不足的地方，或许日后支援摘要认证 (Digest) 及使用 MD5 编码后，可以解决这种问题。之后每一页仍然需要帐号及密码，只不过浏览器会帮你主动送出，不用再输入帐号密码了。这方面浏览器会保留到被关闭为止，下次重执行浏览器仍需输入第一次。
在使用者数量少时，使用上述的方法轻松又省事。但是在使用者有数万人，甚至数十万人时，会发生整个伺服器的效率都被搜寻帐号密码下拖垮，可能读取一页需要数十秒到数分钟。这种情形再使用伺服器提供的密码查核机制就不太明智了。在Netscape Enterprise Server 上可能就可以使用 NSAPI 来开发自己的查核方式，在IIS
自 CERN httpd 之后的 Web 伺服器大部份都提供了使用者身份确认的功能。仅管每套 Web 伺服器的设定都不太相同，但在设定上都大同小异。
以下就是 Apache 伺服器上的使用者身份确认的设定。
<Directory /home/MyMember>
AuthType Basic
AuthName MyMember
AuthUserFile /usr/local/MyMember.txt
Options Includes ExecCGI
<Limit GET POST>
require valid-user
</Limit>
</Directory>
在这个例子中，当使用者在看 MyMember 目录下所有的档案，包括图片档案及其它各式档案时，都需要使用者的帐号密码确认。而使用者的帐号及密码档都存在于/usr/local/MyMember.txt 之中。
这个帐号密码档 /usr/local/MyMember.txt 的样子可能如下例。其中冒号前的字串是使用者帐号，冒号之后的字串是经过不可还原加密的密码，编码一般都是使用传统的 DES 编码，密码的头二个字是类似种子的字元 (salt)，本例中都是 3P。每行代表一位使用者。当然 Webmaster 要自行控制重覆帐号的情形。比较特殊是在 Win32 系统上架 Apache 的情形，冒号后的密码不可加密，因为 Win32 没有提供这方面的编码
API，因此使用者密码以明码的方式存在。
john1234:3PWudBlJMiwro
queenwan:3PFNVLNPN9W0M
noname00:3PEsXaJx5pk7E
wilson49:3PjoWb0EnaG22
rootboot:3PIt0snI6.84E
sun_moon:3PvymMeNOc.x.
nobody38:3PbskPKwV94hw
在 Apache 1.3.6 版上，可以用 ~apache/bin/htpasswd 来产生单笔的帐号及密码，但对于需要大笔资料的商业站台，可能就需要自行写程式来处理了。UNIX 上需要呼叫 crypt() 来处理编码。
在一切都设定好了之后，连线时就会在浏览器出现查核密码的视窗，如上图就是SEEDNet 的 MySEED 网站的使用者查核机制。在输入了帐号及密码后，浏览器会将它用BASE64 编码后，传到伺服器端。当然 BASE64 只是编码不是加密，因此在网路上这种传输的安全性仍然不高，还是有可能被中间的刽客截下，再将 BASE64 还原，这也是整个使用者认证中最美中不足的地方，或许日后支援摘要认证 (Digest) 及使用 MD5 编码后，可以解决这种问题。之后每一页仍然需要帐号及密码，只不过浏览器会帮你主动送出，不用再输入帐号密码了。这方面浏览器会保留到被关闭为止，下次重执行浏览器仍需输入第一次。
在使用者数量少时，使用上述的方法轻松又省事。但是在使用者有数万人，甚至数十万人时，会发生整个伺服器的效率都被搜寻帐号密码下拖垮，可能读取一页需要数十秒到数分钟。这种情形再使用伺服器提供的密码查核机制就不太明智了。在Netscape Enterprise Server 上可能就可以使用 NSAPI 来开发自己的查核方式，在IIS
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
热门文章
