关于GWT的问题，Cookies和网页导航 [英] question on GWT, Cookies and webpage directing

问题描述

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

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

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

网络应用程序中的注销按钮将删除Cookie中的信息，并将您带到登录页面（删除Cookie信息，并引导您到网页的登录部分）。

或者会有不同的方法。

解决方案

我会说你差不多：D在我的应用程序中处理登录/注销：

1. 用户加载页面 - 如果他有一个设置了 strong>（请参阅下一点了解更多信息），将该令牌发送到服务器，以检查它是否仍然有效。如果有效，您已登录，请转到第5点。有关如何处理无效令牌，请参阅下面的注释。


2. 用户输入用户/密码组合。这些信息被发送到服务器（最好通过加密连接发送，但很难用GWT实现 - 例如，请参阅
   
3. 服务器检查用户/ 密码哈希（见下文）组合是否匹配与什么在数据库/什么。如果是这样，它会生成令牌（只是一些随机的长字符串，例如 UUID ）并将其发送回客户端。


4. 如果用户在登录期间选中记住我复选框，请将令牌存储在未来到期日期


5. 当客户端收到令牌时，应该使用每个请求您希望只有经过身份验证的用户才能执行的服务器。在那里，服务器检查令牌是否有效（你必须跟踪你的DB中的令牌/用户对），如果是，授权事务/任何。 以下是抓住：如果您只在Cookie上使用 ，则会容易受到 XSRF攻击。这就是为什么你应该传递令牌（cookie被自动传输 - 这就是为什么XSRF攻击是可能的）作为请求的一部分（你知道，像JSON中的一个附加字段或通过GWT发送的POJO中的字段， RPC或甚至在HTTP头中）。


6. 在显式注销时（点击注销链接等），向用户刚刚注销的服务器发送信息。服务器应该然后删除/使令牌无效。它应该这样做，无论记住我选项 - 因为显式注销意味着用户想删除在该PC /浏览器上的登录信息，并防止他人以他/她的身份登录。如果用户只是关闭浏览器/页面，并且您已经在第4点正确设置了Cookie（也就是说，它不会在浏览器关闭时再次过期，只有选择了记住我选项），下次访问




一些额外的笔记






• 这非常重要：请记得在服务器端检查通过cookie传递的令牌是否等于请求/有效内容中传递的令牌。


• 不要将密码以纯文本 - 密码的存储哈希值存储在数据库中。使用BCrypt最大的安全性。这就是为什么我写的应该比较密码哈希，而不是实际的密码。


• 当服务器遇到无效的令牌时，的东西 - 从正常到警报。一般来说，记录这些情况并定期检查日志中的异常活动是很好的。
  
  
  
  
  1. 用户没有访问过该网站，而是该令牌已过期。确保您在客户端正确处理令牌到期（cookie的正确过期日期应导致用户被重定向到登录页面，而不发送过期的令牌）和服务器端（每日扫描令牌列表并删除）
  
  
  2. 也许您对令牌验证设置了其他限制 - 例如令牌无法过期和
  
  
  3. 发送请求时出现错误，并且其格式不正确/ corrupted - 无法对此进行太多操作，但将用户重定向到登录页面
  
  
  4. 第三方正尝试使用手工制作的令牌登录 。如果你使用愚蠢的容易猜到的令牌（例如基于用户名，rot13，自己的超级特别的加密等），然后你会迟早被咬这个迟早。 UUID是良好令牌候选的示例 - 顾名思义，它是一个通用唯一的标识符 - 意味着没有两个用户应该具有相同的UUID，UUID本身是随机和长的。
  
  







我看到了太多的网络应用程序，容易利用安全漏洞...请务必了解完全什么和为什么你在做。如果您有任何问题，请随时询问：）





---





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




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.

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.

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,

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).

or would there be a different approach.

解决方案

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

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.

Some additional notes

• 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. 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.

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 :)

---

Update 2015-06-12: GWT - Security RPC XSRF

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