我正在为我的网站使用 .htaccess 身份验证。使用 AD vi LDAP 进行身份验证后,如何在浏览器中创建经过身份验证的用户的会话和 cookie,以及重定向实际发生在我的网站的位置。请为此提供帮助或分享任何解释此过程的链接。
1 回答
查看BASIC 身份验证和DIGEST 身份验证的 wiki 页面,它们都是协议 (HTTP) 上的身份验证机制。基本上,这就是浏览器所看到的(此处重述):
- 尝试请求 URI,网络服务器回复 401 响应和
WWW-Authenticate
标头 - 此标头包含一个 REALM,有点像一组都属于同一个身份验证领域的页面
- 浏览器会弹出一个模式对话框,询问用户名和密码。
- 根据 BASIC 或 DIGEST,该密码将与导致 401 的原始请求一起发送回网络服务器。
- 如果凭据不正确,则会返回 403,并且浏览器会显示相应的错误消息。否则,网络服务器返回请求的页面。
- 浏览器知道此 URL 属于 REALM,因此每次请求此 URL 时,都会自动随请求一起发送授权。
- 如果浏览器请求其他也需要身份验证的东西,并且它属于同一个 REALM,则当 Web 服务器返回 401 和 REALM 时,浏览器将自动发送授权。
使用 REALM 信息和凭据列表配置 Web 服务器的方式各不相同。它可以连接到 LDAP 数据库、活动目录、带有散列密码的平面文件等。
这与 cookie 或其他 webapp 级别的身份验证不同,因为它不使用 HTTP 协议进行身份验证。webapp 有一个包含用户名和密码表单的页面,这些表单通过 POST/GET 请求作为参数发送,由 webapp 确定这些凭据是否有效。如果它们是有效的,webapp 可以选择将会话 ID 存储为 cookie,以便浏览器可以继续浏览 webapp 提供的页面。
此身份验证与 HTTP 身份验证之间的最终用户区别之一是 webapp 可以删除 cookie,或使该会话无效,实质上是将用户从 webapp 中注销。这在 HTTP 身份验证中实际上是不可能的,因为浏览器在请求同一 REALM 下的页面时会盲目地提交授权标头。解决此问题的一种方法是在请求受保护的页面时使网络服务器强制返回 403。
另一个区别是,使用 HTTP 身份验证时,您可以在 URL 中包含用户名/密码。http://user:pass@host.com 身份验证如何工作?
另请参阅:http ://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet ,以获得对一般身份验证的更完整描述。