基本上有两种方法可以在您的平台上通过 HTTP 实现用户身份验证:
- “经典”基本 HTTP 身份验证(请参阅 RFC2616 了解确切规范),
- 登录表单,创建会话 ID,并将其返回给浏览器,以存储在 cookie 或 URL 中。
基本 HTTP 身份验证的工作原理是您在网页服务例程中插入一个检查,以查看是否存在 Authorization HTTP 标头。如果有,您应该对其进行解码(参见 RFC),并检查指定的用户名/密码。如果凭据正常,则继续提供网页。如果凭据不正确,或者没有 Authorization 标头,则应返回 401 错误代码。然后浏览器将提示用户输入凭据。这个解决方案相当简单,您会看到浏览器登录对话框,而不是漂亮的 HTML 页面。此外,微控制器必须检查每个页面请求的凭据。
通过登录表单进行身份验证由您的服务器维护正确身份验证的用户会话列表(可能在内存中),并根据该列表检查请求。登录后,应为该会话生成一个唯一的随机 ID,并将会话数据输入到您的列表中。新的会话 ID 应该返回给浏览器以包含在即将到来的 HTTP 请求中。您可以选择将会话 ID 放入浏览器 cookie,也可以将其作为 URL 参数 (?id=xxxxx) 嵌入到 URL 中。通过向具有新 URL 的浏览器发送 302 重定向响应来嵌入 URL 参数。如果您需要 cookie 解决方案,您可以使用 Set-Cookie HTTP 响应标头发送对登录请求的响应。在登录表单解决方案中,实际凭据(用户名/密码)仅在登录时检查一次。之后,仅根据活动会话列表检查会话 ID。会话 ID 必须从每个网页服务的请求中提取(从 URL 或从 Cookie HTTP 标头)。此外,您必须实现某种会话超时,既作为一种安全措施,又要限制活动会话列表的大小。
现在是更难的部分:在这两种解决方案中,用户名/密码在一些请求中传播(在基本 HTTP 身份验证的每个请求中,以及登录表单解决方案的登录页面 POST 中),并且可以从网络流量中提取。此外,两种解决方案的每个请求中都存在劫持会话所需的信息。如果这是一个问题(系统在可自由访问的 LAN 网段上工作,或通过您无法控制的网络链接),您可能需要 SSL 来隐藏这些敏感数据。如何为您的平台获得合理的 SSL 实现,这是另一个问题。