tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <>
Subject Re: Not quite a tomcat question
Date Sun, 31 Dec 2006 13:24:22 GMT
Despitie writing in the db would clearly be the better idea, I'd
suggest that you create a unique id (its easy using 30 random digits
or something) and put the users data in a large hashmap along with a
timestamp of the creation and the users data. You can include this id
into the confirmation link (if you carry about security than
md5-hashcoded with a secret and/or timestamp).
The hashmap is held in application scope or in a static variable
somewhere or in a singleton class. Whenever the user clicks the
confirmation link you can lookup his data in the hashmap.
To prevent the map from getting VERY large you can scan it every hour
and check whether the confirmation is expired (that's why the
timestamp should be included).
You can further make a context listener and dump the hashmap contents
to a file upon shutdown, and load from file when starting.

Of course the access to the map should be synchronized.


On 12/31/06, EDMOND KEMOKAI <> wrote:
> Happy New Year All.
> Does anyone use sessions to temporarily hold confirmation codes for user
> registrations? I have a setup where when the user registers a random
> confirmation code is generated and appended to a url which is emailed to the
> user. The user's registration data is stored in a session with the
> confirmation code as the key. When they click the confirmation link, the
> code is used to retrieve the registration information and the registration
> is done. Some users are having trouble because it seems they're encountering
> invalidated sessions. I know if  the registrations is done in one browser
> and the link (outlook will open IE) opens up a different browser that would
> lead to the creation of a different session which obviously wouldn't have
> the registration data. I have seen implementations that enter the
> confirmation directly into the database but I don't want to do that since it
> would mean writing more code to check who's account is activated and who's
> hasn't, and also might lead to garbage in the database of users who never
> activated their accounts...Any suggestions?
> --
> "talk trash and carry a small stick."

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message