关于 GWT、Cookies 和网页定向的问题 [英] question on GWT, Cookies and webpage directing

问题描述

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

i am using gwt to create a website. this question is regarding a login page and cookies to save login details. GWT allows you to create a website within a single webpage.

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

my application runs on one webpage. i have the application set up as , there is a login box with a login button, and if the details are correct it will load up the underlying UI and removes the login box.

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

so that means every time i refresh my page the application brings me to the login page. is there anyway to set up a cookie that hold the information of the user for example a day, that would input the details into the login box and sign in automatically,

Web 应用程序中的注销按钮也会删除 cookie 中的信息并将您带到登录页面(删除 cookie 信息并将您定向到网页的登录部分).

also the logout button within the web app would remove the information in the cookie and bring you to the login page (remove the cookie information and direct you to the login part of the webpage).

或者会有不同的方法.

推荐答案

我想你几乎做对了 :D 以下是我在我的应用程序中处理登录/注销的方式:

I'd say you almost got it right :D Here's how I handle login/logout in my application:

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

1. The user loads the page - if he has a cookie set with a token (see next points for more info), send that token to the server to check if it's still valid. If it's valid, you are logged in, go to point 5. See notes below on how to handle an invalid token.
2. The user inputs user/pass combination. This information is sent to the server (it'd be best to send it over an encrypted connection, but it's hard to achieve with GWT - for example, see this question).
3. The server checks if the user/password hash (see below) combination matches with what's in the database/whatever. If so, it generates a token (just some random, rather long string, like an UUID) and sends it back to the client.
4. If the user checked the "Remember me" checkbox during login, store the token in a cookie with a future expiration date (refer to other guides/questions on what is the recommended time period).
5. When the client receives the token, it should use it for every request made to the server that you want only authenticated users to perform. There, the server checks if the token is valid (you have to keep track of token(s)/user pairs in your DB) and if so, authorize the transaction/whatever. Here's the catch: if you rely only on the cookie, you'll be vulnerable to a XSRF attack. That's why you should pass the token also (the cookie is transferred automagically - that's why a XSRF attack is possible) as part of the request (you know, like as an additional field in JSON or a field in a POJO you send via GWT-RPC or even in the HTTP header).
6. On explicit logout (clicking the "Logout" link, etc.), send an information to the server that this user has just logged out. The server should then delete/invalidate the token. It should do this regardless of the "Remember me" option - since explicit logout means the user wants to delete login information on that PC/browser and prevent others from logging in as him/her. If the user just closes the browser/page and you've set the cookie correctly in point 4 (meaning, it won't expire on browser close - again, only if the "Remember me" option was chosen), on next visit the user should get automatically logged-in in point 1.

一些附加说明

• 这一点非常重要:记得在服务器端检查通过 cookie 传递的令牌是否等于作为请求/有效负载的一部分传递的令牌.
• 不要将密码以纯文本形式存储在数据库中 - 存储密码的哈希值.使用 BCrypt 以获得最大的安全性.这就是为什么我写道您应该比较密码哈希，而不是实际密码.
• 当服务器遇到无效令牌时，这可能意味着很多事情 - 从正常到警报.一般来说，最好记录这些情况并定期检查日志是否有任何异常活动.

• This is very important: remember to check on the server side if the token passed through the cookie equals the one passed as part of the request/payload.
• Don't store the passwords in your database as plain text - store hashes of the passwords. Use BCrypt for maximum security. That's why I wrote that you should compare password hashes, not the actual passwords.
• When the server encounters an invalid token, this can mean a number of things - from normal to alerting. In general, it's good to log these situations and regularly check the logs for any abnormal activity.

1. 用户已经很长时间没有访问该网站，并且令牌已过期.确保在客户端正确处理令牌过期(cookie 上的正确过期日期应该导致用户被重定向到登录页面，而不发送过期的令牌)和服务器端(每天扫描令牌列表并删除令牌的特殊任务)过期的?)
2. 也许您对令牌验证设置了一些其他限制 - 例如令牌不能过期并且当前尝试必须来自与该相同的 IP令牌最初是为其生成的.
3. 发送请求时出现错误，并且格式错误/损坏 - 对此无能为力，但将用户重定向到登录页面
4. 第三方正在尝试使用手工制作的令牌登录.如果您使用非常容易猜测的令牌(例如基于用户名、rot13、自己的超级特别棒的加密"等)，那么您迟早会被它咬到.UUID 是一个好的令牌候选者的例子——顾名思义，它是一个普遍唯一标识符——意味着没有两个用户应该拥有相同的 UUID，并且 UUID 本身是随机的和长的.

1. User hadn't visited the site for a looong time and the token expired. Make sure you handle token expiration properly on client side (correct expiration dates on cookies should result in the user being redirected to the login page, without sending the expired token) and server side (a special task that scans daily the token list and deletes the expired ones?)
2. Maybe you've put some other restrictions on token validation - like the token can't be expired and the current attempt must be from the same IP as the one the token has been originally generated for.
3. There was an error when sending the request and it came malformed/corrupted - can't do much about this, but redirect the user to the login page
4. A third-party is trying to log in using a handcrafted token. If you use stupidly easy to guess tokens (like based on the username, rot13, own super-special-awesome "encryption" etc.) then you will get bitten by this sooner or later. UUID is an example of a good token candidate - as the name implies, it's a universally unique identifier - meaning no two users should have the same UUIDs and the UUIDs themselves are random and long.

AJAX 应用程序的安全性很重要 - 我见过太多的 Web 应用程序容易利用安全漏洞...确保您完全理解什么以及为什么你在做什么.如果您有任何问题，请不要犹豫，问:)

Security in AJAX applications is serious business - I've seen too many web applications with easy to exploit security holes... Make sure you understand completely what and why you are doing. If you have any questions, don't hesitate to ask :)

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

这篇关于关于 GWT、Cookies 和网页定向的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！