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
