-ee -er_EE协作登录系统-设计注意事项

-ee -er

Preface

前言

In the first article: A Better Website Login System I introduced the EE Collaborative Login System and its intended purpose.

在第一篇文章： 更好的网站登录系统中，我介绍了

In this article I will discuss some of the design considerations and give a more comprehensive overview of the Login System. You do not need to know this information in order to implement some or all of the Login System on your web site. Based on feedback from this article, certain aspects of the Login System may even change.

在本文中，我将讨论一些设计注意事项，并对登录系统进行更全面的概述。 您无需了解此信息即可在您的网站上实施部分或全部登录系统 。 根据本文的反馈， 登录系统的某些方面甚至可能会更改。

"Security by obscurity is no security"

With that in mind, presenting the design considerations and source code to public scrutiny means that someone will find an erroneous assumption or some important detail that was not originally considered. This process of public review, especially on a site with hundreds of subject matter experts, will result in better, more robust, and more secure code.

考虑到这一点，将设计注意事项和源代码呈现给公众审查意味着某人会发现一个错误的假设或一些最初未考虑的重要细节。 这种公共审核过程，尤其是在拥有数百名主题专家的网站上，将产生更好，更健壮和更安全的代码。

1个 (1)

IntroductionI previously asserted that the Login System is actually an Authentication and Authorization system.  Authentication being "prove who you are" by logging in and authorization being "do you have permission to access a given resource."  The user's table of the Login System has a text field called "userRoles." Each person who registers is assigned the user role of Guest. The web developer or webmaster is free to add a comma delimited set of roles to that field, such as "Member, Moderator, Administrator" which would assign the user three roles. No database access code has been provided to access that field although it will be added as an enhancement in future versions.

简介我之前曾断言登录系统实际上是一个身份验证和授权系统。 身份验证通过登录来userRoles ”的文本字段。 每个注册人员都分配有来宾用户角色。 Web开发人员或网站管理员可以自由地在该字段中添加一组用逗号分隔的角色，例如“成员，主持人，管理员”，该角色将为用户分配三个角色。 没有提供数据库访问代码来访问该字段，尽管它将在以后的版本中作为增强功能添加。

2 (2)

How The Login System Works

登录系统如何工作

Ignoring implementation details for a moment I will discuss how the Login System functions. The web developer has the choice to implement or not implement any portion of the Login System.

暂时忽略实现细节，我将讨论登录系统的功能。 Web开发人员可以选择实施或不实施登录系统的任何部分。

Before any person can login they must first have a user account. If the webmaster is not going to manually add users to the database, then the registration form would be used.  For security reasons, a user must supply a valid email address and must accept session and permanent cookies from the website. If they fail to meet these minimal restrictions they can not register or login to the website. Why this requirement was made in the Login System will become apparent as you read on.

任何人都必须先拥有一个用户帐户，然后才能登录。 如果网站站长不打算手动将用户添加到数据库，则将使用注册表格。 出于安全原因，用户必须提供有效的电子邮件地址，并且必须接受来自网站的会话和永久cookie。 如果他们无法满足这些最低限制，则无法注册或登录该网站。 当您继续阅读时，为什么在登录系统中做出此要求的原因将变得显而易见。

3 (3)

The database structure

数据库结构

The Login System currently uses 5 tables. These are;

登录系统当前使用5个表。 这些是;

2.      loginAttempts

2. loginAttempts

3.      logins

3.登录

4.      securityQuestions

4.安全问题

5.      questions

5.问题

The currently released code is robust and secure in and offers a better alternative to many options available to web developers. That there are future enhancements in the pipeline should not prevent the system from being implemented. In fact, knowing a system is evolving for the better should be reassuring to implementors as they know they are not implementing an abandoned project.

当前发布的代码功能强大且安全，可以为Web开发人员提供许多可选的更好的选择。 管道中将来有增强功能不应妨碍系​​统的实施。 实际上，了解系统正在不断发展，应该使实施者放心，因为他们知道他们没有实施废弃的项目。

As designed, enhancements will primarily only require a new page being copied over an existing page. Enhancements which require a change to loginGlobals or the database structure will be kept to a minimum unless offer significant improvement or are mandated by security needs.

按照设计，增强功能主要只需要在现有页面上复制一个新页面。 需要更改loginGlobals或数据库结构的增强功能将保持在最低限度，除非提供显着改进或出于安全需求的要求。

The users table has the following fields:

users表具有以下字段：

ID               int Identity   not null    primary key 
dateRegistered   datetime       not null 
userid           nvarchar(50)   not null 
password         nvarchar(255)  not null 
name             nvarchar(100)  not null 
email            nvarchar(100)  not null 
IP               nvarchar(32) 
region           nvarchar(50) 
city             nvarchar(50) 
country          nvarchar(50) 
useragent        nvarchar(255) 
website          nvarchar(100) 
news             nvarchar(3) 
locked           char(1)        Default 1 
dateLocked       datetime 
token            nvarchar(64) 
deleted          char(1)        Default 0 
dateDeleted      datetime 

4 (4)

RegistrationThe real work of the user's table is during the registration process and you can not log in unless you have a user account so let's examine registration.  ID and dateRegistered should be self-explanatory.  The UserID field can be up to 50 characters and the password field can be a passphrase of up to 255 characters. As both fields can accept whitespace and some punctuation characters, this can greatly enhance security.  (It should be noted that plain text password are never stored in the system but are hashed with a salt prior to being inserted into the table.  In the present code base, there is no minimum password requirement or password strength measurement. That will be changed in a future version but will only require that the registration page be replaced with a new version.

注册用户表的实际工作是在注册过程中，除非您具有用户帐户，否则您无法登录，因此让我们检查一下注册。 ID和注册日期应该是不言自明的。 UserID字段最多可以包含50个字符，而密码字段可以是最多255个字符的密码。 由于两个字段都可以接受空格和某些标点符号，因此可以大大提高安全性。 （应注意，纯文本密码从不存储在系统中，而是在插入表之前先用盐进行哈希处理。在当前代码库中，没有最低密码要求或密码强度度量。这将更改在将来的版本中，但仅要求将注册页面替换为新版本。

Region, City, and Country may seem odd, but the registration IP is geo-located and that information is recorded for auditing purposes. It could be very useful to see where a user exists when registering for an account. This can also be used to limit access to the site to users from a specific location, for example a company selling products in only one country may want to prevent registration from users from differing countries.

地区，城市和国家可能看起来很奇怪，但是注册IP处于地理位置，并且记录了该信息以用于审核。 在注册帐户时查看用户的位置可能非常有用。 这也可以用于限制用户从特定位置访问网站，例如，仅在一个国家/地区销售产品的公司可能希望阻止来自不同国家/地区的用户进行注册。

Similarly, the useragent and website address are simply informational, but may be wanted by some webmasters for various purposes.  News allows the user to opt in to receiving newsletters or e-mails about site changes from the webmaster.  These fields can be ignored and website and news can be removed from the register page's markup if the web developer does not wish to receive that information.

同样，用户代理和网站地址仅供参考，但某些网站管理员可能出于各种目的而需要它们。 新闻允许用户选择接收来自网站管理员的有关站点更改的新闻通讯或电子邮件。 如果Web开发人员不希望接收这些信息，则可以忽略这些字段，并且可以从注册页面的标记中删除网站和新闻。

Email, locked, dateLocked, and token work together at registration to ensure the user is a valid user. (Actually that the user at least supplied a valid email address.) When a person registers they are required to provide a valid email address. Rather than granting immediate access, a cryptographic token is sent to the email address entered during registration. At the same time the new account is marked locked, the dateLocked is recorded and the token stored for later validation.

电子邮件，锁定，日期锁定和令牌在注册时一起使用，以确保该用户是有效用户。 （实际上，用户至少提供了一个有效的电子邮件地址。）当一个人注册时，要求他们提供一个有效的电子邮件地址。 而不是立即授予访问权限，而是将加密令牌发送到注册期间输入的电子邮件地址。 同时将新帐户标记为已锁定，记录dateLocked并存储令牌以供以后验证。

Upon receiving the email with the validation token, the user must either click a link in the email to send the token back to the website, or copy the token from the email and paste it into the registration validation page. If the user successfully validates their email address, the account is unlocked, and the dateLocked and token fields are set to Null.  At that point the user may login to the website.

收到带有验证令牌的电子邮件后，用户必须单击电子邮件中的链接以将令牌发送回网站，或者从电子邮件中复制令牌并将其粘贴到注册验证页面中。 如果用户成功验证其电子邮件地址，则该帐户将被解锁，并且dateLocked和token字段将设置为Null。 此时，用户可以登录该网站。

Now, this is unlikely, but not impossible. A malicious user may attempt to open an account using another person's details. Thus, there is a link in the validation email for a person to click to delete the registration. It should be noted that for audit purposes the account simply has the deleted field set to "1" (one) and the dateDeleted recorded. The record is not removed from the table.

现在，这不太可能，但并非不可能。 恶意用户可能会尝试使用他人的详细信息来开设帐户。 因此，验证电子邮件中有一个链接，供用户单击以删除注册。 应当注意，出于审计目的，帐户仅将已删除字段设置为“ 1”（一个），并记录dateDeleted。 记录不会从表中删除。

Just to register a user involves three pages! The registration form page, the registration verification page, and the registration delete page.  As an added measure of security, the forms in the Login System implement a cryptographic one time use token to prevent CSRF attacks. This means a user must actually visit the site to load the form in order to get the form token and the form token must be unchanged when the form is submitted. (This token is also stored on the user's computer which is one of the reasons permanent cookies need to be accepted for use of the Login System.)

仅注册一个用户就需要三页！ 注册表单页面，注册验证页面和注册删除页面。 作为一种额外的安全措施，登录系统中的表单实施了一种加密的一次性令牌，以防止CSRF攻击。 这意味着用户必须实际访问站点以加载表单才能获取表单令牌，并且提交表单时表单令牌必须保持不变。 （此令牌也存储在用户的计算机上，这是使用登录系统需要接受永久cookie的原因之一。 ）

This prevents someone from creating their own form or a specially crafted link to submit registrations. This also means there could be an error involving the form token. The potential errors are;

这样可以防止某人创建自己的表单或特制的链接来提交注册。 这也意味着可能存在涉及表单令牌的错误。 潜在的错误是；

2.      A form timeout issue, (they have 5 minutes to complete any form,)

2.表单超时问题，（他们有5分钟的时间填写任何表单，）

3.      A token error, (the token is empty, invalid, or was tampered with.)

3.令牌错误（令牌为空，无效或被篡改。）

Of the three, the token error could be caused by a user submitting a form, (which consumes the token,) then using their browser's back button to return to the previously submitted form, which would then have an invalid token. Not a common occurrence, but it happens.

在这三个中，令牌错误可能是由于用户提交表单（使用令牌）然后使用其浏览器的“后退”按钮返回到先前提交的表单而导致的，该表单将具有无效的令牌。 这不常见，但是会发生。

The form error page, (yes now a forth page,) supplied with the example code handles the errors quite simply, and in the case of a person who used their browser's back button to return to a previously submitted form, it provides a link so the user can re-enter the form properly and receive a fresh token.

示例代码随附的表单错误页面（现在是第四页）非常简单地处理了错误，对于使用浏览器的后退按钮返回到先前提交的表单的用户而言，它提供了一个链接，因此用户可以正确地重新输入表格并获得新的令牌。

The tokens are sufficiently random that no table was added to track used tokens. This could potentially be a problem and may be changed in future versions. Replay attacks are not really feasible the way the tokens are created and considering a corresponding cookie must exist, but tracking previously used tokens would add little overhead and increase security.

令牌具有足够的随机性，因此未添加任何表来跟踪已使用的令牌。 这可能是一个问题，并且可能在将来的版本中进行更改。 重播攻击在创建令牌和考虑必须存在相应cookie的方式上并不切实可行，但是跟踪先前使用的令牌将增加很少的开销并提高安全性。

Phew...that was just registration, we haven't even talked about logins yet. As a matter of fact we have not discussed all the security measures of the registration process.

...这只是注册，我们甚至还没有谈论登录。 实际上，我们还没有讨论注册过程中的所有安全措施。

Coupled with the anti-CSRF token, all form input is validated for correctness. By that I mean input must pass a white list of acceptable characters for the given field. An improperly formed email address would be rejected out of hand. Input is not echoed back to the screen unless it is first HTML encoded. Between filtering and HTML encoding we will have no XSS vulnerabilities. Likewise the use of parametrized SQL along with the filtering of data virtually eliminates the possibility of a SQL injection vulnerability.

结合反CSRF令牌，所有表单输入都经过验证是否正确。 我的意思是，输入必须为给定字段传递可接受字符的白名单。 格式不正确的电子邮件地址将被拒绝。 除非首先进行HTML编码，否则输入不会回显到屏幕上。 在过滤和HTML编码之间，我们将没有XSS漏洞 。 同样，将参数化SQL与数据过滤一起使用实际上消除了SQL注入漏洞的可能性。

These security mechanisms are used on all Login System pages which display outside data or access the database.  Login  Assuming a person has validated their email address they are permitted to login. As mentioned, a new user is assigned the role of guest so if the website has need of differing permissions, guest should be a low permission account. It is up to the webmaster to determine and assign greater levels of permissions to an account.

这些安全性机制用于显示外部数据或访问数据库的所有“登录系统”页面上。 登录假设某人已验证其电子邮件地址，则可以登录。 如前所述，为新用户分配了访客角色，因此，如果网站需要不同的权限，则访客应为低权限帐户。 由网站管理员决定并为帐户分配更高级别的权限。

In the global configuration file there is a setting, lg_login_attempts which is set at 5 which means if a user fails to authenticate in five tries their account is locked. This is where the loginAttempts table comes into play. Let's look at those fields.

在全局配置文件中，有一个设置lg_login_attempts设置为5，这意味着如果用户五次尝试认证失败，则其帐户将被锁定。 这是loginAttempts表起作用的地方。 让我们看看这些字段。

 
ID                  int Identity   not null    primary key 
loginAttemptUserID  nvarchar(50) 
loginAttemptNumber  int 
loginAttemptDate    datetime 
loginAttemptIP      nvarchar(32) 
loginAttemptLocked  char(1)        Default 0

If a user knows they have five login attempts before they lockout their account, and if we count the attempts using a session variable, the user only needs to close their browser after 4 attempts, then reconnect to get five more attempts.  Clearly this won't suffice.  Also, if a malicious user came along and randomly tried guessing userids, (say admin,) and passwords hoping to get lucky that user could also close and reopen their browser to reset the session counter.

如果用户在锁定帐户之前知道他们进行了五次登录尝试，并且如果我们使用会话变量对尝试进行计数，则用户仅需在尝试4次后关闭浏览器，然后重新连接即可获得五次尝试。 显然，这还不够。 同样，如果恶意用户出现并随机尝试猜测用户ID（例如admin）和密码，希望很幸运，该用户还可以关闭并重新打开其浏览器以重置会话计数器。

For security, we need to track the login attempts in a table so we do not forget how many login attempts were made. Also, we want to not just track the userid but the remote IP as well. By tracking this in a table we can enforce our five attempts before lockout and we are not just locking a user account we are also banning the remote IP.

为了安全起见，我们需要在表中跟踪登录尝试，因此我们不会忘记进行了多少次登录尝试。 另外，我们不仅要跟踪用户ID，还要跟踪远程IP。 通过在一个表中跟踪此行为，我们可以在锁定之前强制执行五次尝试，我们不仅锁定了用户帐户，而且还禁止了远程IP。

From a security standpoint this is only fairly good. We have an audit trail for failed login attempts and we can assure a user at some remote IP is limited to our set number of login attempts. But, we need to recognize there are ways to spoof an IP address, (potentially bypassing our protections.)

从安全角度来看，这仅是相当不错的。 我们具有针对失败登录尝试的审核跟踪，并且可以确保某些远程IP上的用户限于我们设置的登录尝试次数。 但是，我们需要认识到存在欺骗IP地址的方法（可能绕过我们的保护措施）。

A malicious user could perform a denial of service on another user's account simply by intentionally attempting enough bad login attempts with that userid until the account is locked. (This is another reason never to echo userids to the browser.)  The webmaster can detect potentially malicious behavior if the remote IP address does not match the registration IP address. Of course some users may login from different addresses, (home, work, wireless hotspot,) so that is not a sure sign of malicious activity.

恶意用户可以简单地通过对该用户ID进行足够的错误登录尝试，直到该帐户被锁定，从而对另一个用户的帐户执行拒绝服务。 （这是永不向浏览器回显用户ID的另一个原因。）如果远程IP地址与注册IP地址不匹配，则网站管理员可以检测到潜在的恶意行为。 当然，某些用户可能会从不同的地址（家庭，工作，无线热点）登录，因此这并不是恶意活动的肯定信号。

I suggest it is a best practice to inform registered users what the lockout threshold is and allow them to attempt a password recovery before they reach that value.  Of course now we just introduced at least two additional pages to our Login System. A recover password page, and a set new password page. Email is not secure so we can't send a new password to the user and I would argue sending a temporary, one time use password is equally bad. As a result we are back to sending a token to the registered email address of the account owner.

我建议最好的做法是通知注册用户什么是锁定阈值，并允许他们在达到该值之前尝试恢复密码。 当然，现在我们仅向登录系统介绍了至少两个附加页面。 恢复密码页面和设置新的密码页面。 电子邮件不安全，因此我们无法向用户发送新密码，因此我认为发送临时的一次性使用密码同样不好。 结果，我们返回了将令牌发送到帐户所有者的注册电子邮件地址的功能。

This complicates our set new password page as it must first verify the token before permitting the use to set a new password and login.

这会使我们设置新密码的页面复杂化，因为在允许使用它设置新密码和登录之前，它必须首先验证令牌。

Some webmasters may decide this is still weak and require the user to call them by telephone and answer certain questions before unlocking the user's account. Note however, when the user initially signed up we did not require more than a valid email address, to which we sent a verification token. Doing the same to recover a forgotten password is no less secure.

一些网站管理员可能认为这仍然很弱，要求用户在解锁用户帐户之前通过电话给他们打电话并回答某些问题。 但是请注意，当用户最初注册时，我们只需要一个有效的电子邮件地址即可向我们发送验证令牌。 进行同样的操作来恢复忘记的密码同样安全。

Recovering a forgotten userid may call for additional security measures.  It is for that reason the securityQuestions and the questions tables exist. The alpha release of the code does not have pages to allow or make a user select and answer security questions. That is scheduled for a later code release.

恢复被遗忘的用户ID可能需要采取其他安全措施。 因此存在securityQuestions和questions表。 该代码的Alpha版本没有页面来允许或允许用户选择和回答安全问题。 预定在以后的代码发布中使用。

Again, the webmaster is in control. It is entirely possible that the webmaster will assign user accounts and not provide a registration page.  Or a webmaster may allow registrations but not provide a recover password page. That is a perfectly viable solution for a website with a small community of users. Even in that type of environment, to prevent unauthorized access the webmaster must set the login attempts value to a reasonable value.

再次，网站管理员处于控制之中。 网站管理员很有可能会分配用户帐户而不提供注册页面。 或网站管理员可能允许注册，但不提供恢复密码页面。 对于拥有少量用户的网站而言，这是一个完美可行的解决方案。 即使在那种环境下，为了防止未经授权的访问，网站管理员也必须将登录尝试值设置为合理的值。

5 (5)

Successful Login  I have concentrated on the security measures but we need to examine successful logins as well. When a user begins the login process a record is inserted into the login attempts table. If the user successfully logs in, that record must be removed. Failure to do so would eventually lock the user out. If lg_log_logins is set to true, the successful login is logged in the logins table. This provides an audit trail needed by many sites. The logins table contains the following fields:

成功登录我专注于安全措施，但我们也需要检查成功登录。 当用户开始登录过程时，将一条记录插入到登录尝试表中。 如果用户成功登录，则必须删除该记录。 否则，最终将用户拒之门外。 如果lg_log_logins设置为true，则成功登录将记录在logins表中。 这提供了许多站点所需的审核跟踪。 登录表包含以下字段：

ID               int Identity   not null    primary key 
date             datetime 
userid           varchar(50) 
ip               varchar(32) 
useragent        varchar(255) 

There is nothing which should require explanation in this table.  

该表中没有任何内容需要解释。

As HTTP is a stateless protocol, user state (logged in/logged out) is generally handled by session management. Session management varies from one web language to another. In PHP when a user successfully logs in, we can assign a new session id. Doing so, over a secure communications channel, such as that provided by SSL, helps prevent Session Fixation or Replay attacks. While a man-in-the-middle might be able to ascertain the session id of a user who has not logged in and is not using SSL, knowing that session id is of no value after the user logs in, as a new session id is assigned and transmitted only via the encrypted communications channel.

由于HTTP是无状态协议，因此用户状态（登录/注销）通常由会话管理处理。 会话管理从一种网络语言到另一种网络语言都不同。 在PHP中，当用户成功登录时，我们可以分配一个新的会话ID。 这样做是通过安全的通信通道（例如SSL提供的通道）来帮助防止会话固定或重放攻击。 尽管中间人可以确定未登录且未使用SSL的用户的会话ID，但知道该用户登录后该会话ID没有任何价值，则该会话ID是新的会话ID。仅通过加密的通信信道分配和传输“消息”。

The man-in-the-middle can not use the previously obtained session id to act on behalf of the user and usurp the user's account.  Even with SSL, there are possible scenarios where a man-in-the-middle could ascertain the user's session id, but those situations are rare. If we provide adequate defense against XSS vulnerabilities, the user's session id should remain secret.

中间人不能使用先前获得的会话ID代表用户执行操作并篡改用户帐户。 即使使用SSL，在某些情况下，中间人也可以确定用户的会话ID，但是这种情况很少见。 如果我们提供了针对XSS漏洞的充分防御，则用户的会话ID应该保持秘密。

As a further precaution, should a user attempt to perform a valuable transaction, i.e. making a purchase or changing their account details, it would be reasonable and prudent that the web developer require the user to reauthenticate before accepting the transaction.

作为进一步的预防措施，如果用户尝试执行有价值的交易，即进行购买或更改其帐户详细信息，则Web开发人员在接受交易之前要求用户重新进行身份验证是合理和谨慎的。

It is worth noting that ASP does not allow setting a new session id for a user. As a result the developers adopted a method similar to that suggested by OWASP  involving a cryptographic token and cookie which is transmitted only over the SSL tunnel.  Another reason permanent cookies must be accepted by a user.

值得注意的是，ASP不允许为用户设置新的会话ID。 结果，开发人员采用了类似于OWASP建议的方法，其中涉及仅通过SSL隧道传输的加密令牌和cookie。 永久性Cookie必须被用户接受的另一个原因。

Having secured the session we are safe in storing the user's state in the session.  The Login System sets the following session variables upon login.  Session login is set to true, session userid holds the current userid and session name holds the user's name.

确保了会话的安全之后，我们就可以安全地将用户的状态存储在会话中。 登录系统在登录时设置以下会话变量。 会话登录设置为true，会话用户ID保留当前用户ID，会话名称保留用户名。

Session login is used for granting or denying access to pages as demonstrated in the first article. Session userid can be used to customize dynamic content for the user, (for example showing the user his purchase history,) and can be used as a key in looking up the user's assigned roles in the user table for systems which implement role based activities. Session name can be echoed to the browser's screen were personalization is desired.

会话登录用于授予或拒绝对页面的访问，如第一篇文章所述。 会话用户ID可以用于为用户自定义动态内容（例如，向用户显示其购买历史），并且可以用作在用户表中查找用户分配的角色的键，以实现基于角色的活动的系统。 可以将会话名称回显到浏览器的屏幕上，以进行个性化设置。

Finally, in terms of logins, the supplied login form has a "Remember Me" check box that if checked writes a permanent cookie to the browser.  The next time the user visits the login page, the user will be logged in based on the value of the cookie. Since this is weaker than having the user reauthenticate, the cookie value is used to ensure a valid user exists in the user's table and that the user's account is not locked nor the IP banned. Only then is the user authenticated.

最后，就登录而言，提供的登录表单具有“记住我”复选框，如果选中该复选框，则会向浏览器写入永久cookie。 用户下次访问登录页面时，将根据cookie的值登录。 因为这比让用户重新认证要弱，所以cookie值用于确保用户表中存在有效用户，并且该用户的帐户未锁定也不禁止IP。 只有这样，用户才能通过身份验证。

This is still a weak point in the Login System only suitable for low value sites. The field should be removed from the mark up of the login form for online shops or sites which have higher security standards. Again, the option is in the hands of the web developer. Robust code is provided should such a function be desired but the web developer only needs to know how to use the backspace key to remove the field.

这仍然是登录系统中的弱点，仅适用于低价值站点。 对于具有较高安全性标准的在线商店或站点，应从登录表单的标记中删除该字段。 同样，该选项由Web开发人员掌握。 如果需要此功能，则提供健壮的代码，但Web开发人员仅需要知道如何使用退格键来删除该字段。

In fact, in writing this, it occurs to me that future versions should have a configuration setting to disable the "Remember Me" function.

实际上，在撰写本文时，我想到将来的版本应该具有配置设置以禁用“记住我”功能。

6 (6)

Log outTo add yet another page to the Login System, if we allow users to log in we should provide a way to log out. Failing to do so may mean a user's session persists after closing the browser. If the user was on a shared computer, at a library or Internet Cafe, this would potentially allow another person to open a browser and access the site using the persisted user session. To that end, a logout page is provided which destroys all session variables and cookies in use thus positively logging the user out.

注销要向登录系统添加另一个页面，如果我们允许用户登录，则应提供一种注销方法。 否则，可能意味着用户会话在关闭浏览器后仍然存在。 如果用户在共享计算机上，图书馆或网吧中，则可能会允许其他人打开浏览器并使用持久用户会话访问该站点。 为此，提供了注销页面，该页面销毁了所有正在使用的会话变量和cookie，从而积极地注销了用户。

7 (7)

Change PasswordLast but not least, a user may wish to change their password or pass phrase. In fact this should be encouraged as a security best practice. As such we provide a change password page. The user must be logged in before the password or pass phrase can be changed and must be able to supply the current password in order to assign a new one.

更改密码最后但并非最不重要的一点是，用户可能希望更改其密码或密码。 实际上，应鼓励将其作为安全最佳实践。 因此，我们提供了一个更改密码页面。 必须先登录用户，然后才能更改密码或密码，并且必须能够提供当前密码才能分配新密码。

8 (8)

Final Thoughts

最后的想法

This may explain why when a user asks for a login page there is usually more that is necessary. I showed how to create a login page quite simply in the first article about the Login System. It is very nearly "Plug and Play." I'm certain some users will need some assistance setting up their initial database or their settings in loginGlobals, but implementing the pages of the Login System are not difficult.

这可以解释为什么当用户要求登录页面时，通常需要做更多的事情。 在关于登录系统的第一篇文章中，我非常简单地展示了如何创建登录页面。 这几乎是“即插即用”。 我确定某些用户将需要一些帮助来设置其初始数据库或在loginGlobals中进行设置，但是实现Login System的页面并不困难。

By making both the code and the design considerations public, I know the Login System will become more robust and secure.  Before you say it, I'm well aware that several web development platforms or languages have a fine authentication module. That's nice. Did they supply the registration pages, the recover password pages, the change password page?  If not, then there is not a complete authentication and authorization system.

通过公开代码和设计注意事项，我知道登录系统将变得更加强大和安全。 在您说出来之前，我很清楚几种Web开发平台或语言都具有良好的身份验证模块。 真好。 他们是否提供了注册页面，恢复密码页面，更改密码页面？ 如果不是，则没有完整的身份验证和授权系统。

With the talent at Experts-Exchange I hope to see others pick up the gauntlet and assist in translations to other languages, help improve the code base, or port the system to other web development languages.

我希望借助Experts-Exchange的人才，希望其他人也能熟练掌握，并协助翻译成其他语言，帮助改善代码库，或将系统移植到其他Web开发语言。

Use the authentication module from your favorite framework, but use the design guidelines presented here to provide the rest of the Login System in a manner that is simple to implement and maintain.

使用您喜欢的框架中的身份验证模块，但使用此处介绍的设计准则，以易于实现和维护的方式提供其余的登录系统。

For those implementing the Login System, you will find a link at the Google Code project to a forum where FAQs will be posted and various aspects of the system can be discussed. Outside of FAQs, the forum is not intended for support. That's what Experts-Exchange provides.

对于那些实施“登录系统”的用户，您将在Google Code项目上找到一个指向论坛的链接，该论坛将发布常见问题解答，并可以讨论该系统的各个方面。 除常见问题解答外，该论坛不旨在提供支持。 这就是Experts-Exchange提供的。

Contributors:

贡献者：

rdivilbiss     Project Lead rdivilbiss项目负责人

Alphabetically

按字母顺序

b0lsc0tt b0lsc0tt jason1178 杰森1178 jkr k kaushal 考沙尔 lherrou 勒鲁鲁 mark_wills mark_wills ModernMatt 现代马特 mplungjan mplungjan mwvisa1 mwvisa1 Netminder 网民 Ray_Paseur 雷·帕瑟 roonaan 鲁南 RQuadling RQuadling stone5150 石头5150 sunnycoder Sunnycoder

翻译自: https://www.experts-exchange.com/articles/2904/The-EE-Collaborative-Login-System-Design-Considerations.html

-ee -er