Very nicely explained... In the special case when you need the confirmation link to register for a new user account I would additionally recommend the following:
- Let the user enter the initial password for the account when he requests it - Send the link with the token like Daniel explained - When processing the confirmation link with the random UUID token, let the user re-enter his password on link confirmation page This will prevent the hijacking of the confirmation link in the mail since it's useless without the password. IMHO this will cause the least possible annoyance for the user (he needs to set his initial password anyway) Am 29.06.2011 um 21:05 schrieb Daniel Neugebauer: > It's like you already said in your first mail. For one of our websites the > behaviour is: > > 1) generate some kind of a random, unique token > s.th. like UUID.randomUUID().toString() > > 2) register token to user in database > > 3) email link including the token to the user > (use a readily available email library) > > For your application to process the link, the link should end in a > bookmarkable page with a short URL (so it doesn't take too much space in the > email). If you append the token like you usually do (depending on the > UrlCodingStrategy used), the page can get the token by accessing the > PageParameters. If you have multiple types of opt-ins/confirmations (user > accounts, newsletters etc.) then you could use one page to process all tokens > and let it decide which additional page should be instantiated and redirected > to after token verification depending on the token type you saved in your > database. > > On our website we check the token for the correct pattern using a regular > expression and then get the user's email address/data from the database and > let the user confirm his address by re-entering it and continue with an > account setup wizard. However, such a double-safety should rarely be > necessary. We could as well confirm the account right away (or immediately > show/redirect to the wizard instead); once you have the token you know what > user is intended to be accessed so you can do whatever you want. > > Also make sure your tokens will time out after a week or so. You may also > want to count token requests/validations and block users in case the number > gets too high (get the client IP address by accessing the servlet request and > record it somewhere). Maybe we are just a bit too cautious but our > application hosts quite some data, so it can't be wrong. :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
