Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 51426 invoked from network); 31 Dec 2006 01:19:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 31 Dec 2006 01:19:39 -0000 Received: (qmail 62368 invoked by uid 500); 31 Dec 2006 01:19:33 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 62336 invoked by uid 500); 31 Dec 2006 01:19:33 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 62325 invoked by uid 99); 31 Dec 2006 01:19:33 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 Dec 2006 17:19:33 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=HTML_00_10,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ekemokai@gmail.com designates 64.233.162.226 as permitted sender) Received: from [64.233.162.226] (HELO nz-out-0506.google.com) (64.233.162.226) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 30 Dec 2006 17:19:23 -0800 Received: by nz-out-0506.google.com with SMTP id x7so2517048nzc for ; Sat, 30 Dec 2006 17:19:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=JINtHg6t0dRMOwMQsYYlZf/BMqWWXGj1qeBPrrjY6tCzbuUdry8CATDpblReGCE/8rMN6apFDJwMTG3dViuHbcHobCZsEoYdVIVNTSETRISEDan000PqjAgxuXfjJR2n6pqkgEQubC3DtjlGOnbe7bH3lrpXlyynBvbXkv9IoxA= Received: by 10.65.188.20 with SMTP id q20mr12267758qbp.1167527942784; Sat, 30 Dec 2006 17:19:02 -0800 (PST) Received: by 10.65.186.8 with HTTP; Sat, 30 Dec 2006 17:19:02 -0800 (PST) Message-ID: Date: Sat, 30 Dec 2006 20:19:02 -0500 From: "EDMOND KEMOKAI" To: "Tomcat Users List" Subject: Not quite a tomcat question MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_80669_5170301.1167527942753" X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_80669_5170301.1167527942753 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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." PAUL KRUGMAN (NYT) ------=_Part_80669_5170301.1167527942753--