关于GWT,Cookies和网页指导的问题

Question

我正在使用gwt创建一个网站.这个问题是关于登录页面和cookie来保存登录详细信息.GWT允许您在单个网页中创建网站.

我的应用程序在一个网页上运行.我将应用程序设置为,有一个带登录按钮的登录框,如果细节正确,它将加载底层UI并删除登录框.

这意味着每次刷新页面时,应用程序都会将我带到登录页面.无论如何设置一个cookie来保存用户的信息,例如一天,它会将详细信息输入登录框并自动登录,

也是Web应用程序中的注销按钮会删除cookie中的信息,并为您带来的登录页面(删除Cookie信息,并指导你的网页的登录部分).

或者会有不同的方法.

Answer 1

我说你几乎做对了:D这是我在应用程序中处理登录/注销的方法:

1. 用户加载页面 - 如果他有一个带有令牌的cookie集(有关更多信息,请参阅下一个点),将该令牌发送到服务器以检查它是否仍然有效.如果它有效,则表示您已登录,请转到第5点.请参阅下面有关如何处理无效令牌的说明.
2. 用户输入用户/通行证组合.此信息将发送到服务器(最好通过加密连接发送,但使用GWT很难实现 - 例如,请参阅此问题).
3. 服务器检查用户/ 密码哈希(见下文)组合是否与数据库/中的内容相匹配.如果是这样,它会生成一个令牌(只是一些随机的,相当长的字符串,如UUID)并将其发送回客户端.
4. 如果用户在登录期间选中了"记住我"复选框,则将令牌存储在具有未来到期日期的cookie中(请参阅有关建议时间段的其他指南/问题).
5. 当客户端收到令牌时,它应该将它用于每个只向经过身份验证的用户执行的服务器发出的请求.在那里,服务器检查令牌是否有效(您必须跟踪数据库中的令牌/用户对),如果是,则授权事务/其他.这里有一个问题:如果你只依赖cookie,你就容易受到XSRF攻击.这就是为什么你也应该传递令牌(自动转移cookie - 这就是为什么可以进行XSRF攻击)作为请求的一部分(你知道,就像作为JSON中的附加字段或通过GWT发送的POJO中的字段 - RPC甚至在HTTP头中).
6. 在显式注销(单击"注销"链接等)时,将信息发送到该用户刚刚注销的服务器.然后,服务器应删除/使令牌无效.无论"记住我"选项如何,它都应该这样做 - 因为显式注销意味着用户想要删除该PC /浏览器上的登录信息并阻止其他人以他/她的身份登录.如果用户只是关闭了浏览器/页面并且你已经在第4点正确设置了cookie(意味着,它将不会在浏览器关闭时到期 - 再次,只有选择了"记住我"选项),在下次访问时用户应该在第1点自动登录.

一些额外的说明

• 这非常重要:记得在服务器端检查通过cookie的令牌是否等于作为请求/有效负载的一部分传递的令牌.
• 不要将密码作为纯文本存储在数据库中 - 存储密码的哈希值.使用BCrypt可获得最大安全性.这就是为什么我写道你应该比较密码哈希,而不是实际的密码.
• 当服务器遇到无效令牌时,这可能意味着许多事情 - 从正常到警报.通常,记录这些情况并定期检查日志是否有异常活动是很好的.
  1. 用户没有访问该网站一段时间,而且令牌已过期.确保在客户端正确处理令牌过期(正确的cookie过期日期应导致用户被重定向到登录页面,而不发送过期的令牌)和服务器端(每天扫描令牌列表并删除过期的？)
  2. 也许您对令牌验证设置了一些其他限制 - 比如令牌无法过期,并且当前尝试必须来自与最初生成令牌的IP相同的IP.
  3. 发送请求时发生错误并且出现格式错误/损坏 - 无法对此做多少,但会将用户重定向到登录页面
  4. 第三方尝试使用手工制作的令牌登录.如果您使用愚蠢的猜测令牌(例如基于用户名,rot13,自己的超级特殊 - 令人敬畏的"加密"等),那么你迟早会被这种情况所困扰.UUID是一个好的令牌候选者的例子 - 顾名思义,它是一个普遍唯一的标识符 - 意味着没有两个用户应该具有相同的UUID,并且UUID本身是随机的和长的.

AJAX应用程序中的安全性是一项严肃的事情 - 我看到太多的Web应用程序容易被利用安全漏洞......确保您完全理解您正在做什么以及为什么这样做.如果您有任何疑问,请不要犹豫:)

更新2015-06-12: GWT - 安全RPC XSRF