> A really simple trick would be rather than to use a cookie, if
> you are saving state to DB anyway. Set a flag in the DB and test
> for its existence.
>
> sub handler{
> ....
> my $s = session->new();
> $s->continue();
>
> my $flag = $s->get('flag');
> if($flag){
> # do something else
> }
> else{
> # run insert for new signup
> }
> ....
> }
There should be a word for this...
2 minutes after I finished sending my post, I realized exactly this thing.
Since I'm already accessing the DB w/ Apache::Session, I get miscellaneous
flags thrown in for free... since the rest of the signup scripts only uses
the hash keys in %session that it knows about.
So, after a successful signup (read, creation of the new account record in
the database), I simply stash the new acctid into %session:
$session{id} = $id;
Now here's the fun part.
While writing this script originally, I put in a debug statement like so:
# bypass SQL activity
goto TEMPLATE if $ENV{REMOTE_ADDR} eq $my_ip and $session{email} ne
$my_email;
So the next time a signup comes in, I can check for the existence of
$session{id}. If it exists... well, read the updated code:
goto TEMPLATE if exists $session{id} or $ENV{REMOTE_ADDR} eq $my_ip and
$session{email} ne $my_email;
Since the template gets the rest of its values straight from %session
anyway, the only other change I had to make was s/$id/$session{id}/.
Problem solved!
Now, of course, I have to provide for the previous behavior whereby a person
could validly sign up multiple accounts if they were pointing to different
urls, but hey! I've nailed the PROBLEM. Now I just have to adjust the
behaviors slightly.
L8r,
Rob
