[pmwiki-users] PageList Project

marc gmane at auxbuss.com
Sun Jan 28 12:32:29 CST 2007


The Editor said...
> On 1/21/07, marc <gmane at auxbuss.com> wrote:
> > The Editor said...
> > > I really didn't like mailman's approach and ended up using a rather
> > > creative system that makes it easier for an individual to take care of
> > > their subscriptions.  When they visit the newsletter mgmt site, it
> > > asks them to simply enter an email address, and forwards them to an
> > > authentication page.  There, they enter  simple passcode emailed them
> > > (a random number) to verify ownership of the email.  Once verified,
> > > they are forwarded to a subscriptions page which dynamically shows all
> > > current subscriptions, and lets them add or drop subscriptions at the
> > > click of a button.  Pass codes are only valid for 20 minutes and are
> > > tied to specific emails. I think most users will find it much simpler
> > > to use than mailman. Let me know if anyone sees any problems in this
> > > setup.
> >
> > IME, you might hit a problem with this. Sometimes emails become stuck in
> > the system, for a variety of reasons, so time limiting an update code
> > will mean folk having to repeat the process, possibly more than once.
> > That kind of event can drive folk away.
> >
> > An alternative approach is to email the update details as parameters to
> > a URL and embed this in an email. The user then only has to click the
> > link to update their details. Something like:
> >
> > http://www.example.com/Site/ChangeEmailConfirmation?hash=
> > 0e8fc8eafd8506101171031c52d6502b&email=fred%40spammaster.com
> >
> > (Generate the hash by something like:
> >    $hash = md5($newemail.$hiddenHash);)
> >
> > This method never times out.
> 
> 
> Thanks for the idea Marc.

It's not my idea :-) This is standard procedure for this kind of update. 
Been going on for millions of years.

> I don't know much about this hash idea, and
> will read up on it a bit and see what I can come up with.  Though I
> must admit, I'm not so sure I like the idea of them never timing
> out...

Why? I know it's an obvious question, but better to ask why you believe 
a time limit is necessary; what purpose does is fulfill?

What you have is the user's email address stored somewhere - PmWiki page 
or database. The user decides to change their email, so you create a 
hash based on the new email and a secret string - something like:

    $hash = md5($newemail.$hidden_hash_var);

- and email it back to their original email address

    $returnlink = "http://www.example.com/Site/ChangeEmailConfirm";
    $mail->Body = "\nFollow this link to confirm your email change:\n".
                 "$returnlink?hash=$hash".
                 "&email=".urlencode($newemail);

There are many ways to handle the reply. I choose to store the hash with 
the user's details, then find the stored hash on the db:

    $member->load("confirmHash='$hash'")

Next, I check that the dude hasn't got lucky with his hash by 
recalculating it from the found record and comparing it (rehashing it) 
with the incoming email. You could, if you wish, include the member id 
in the email, and avoid any db save at all. Many ways.

> As for the 20 minutes setting, that's just a configurable option that
> can be set to anything.  Could just as easily set it for the big 86400
> seconds or whatever.

But in doing so you've added an admin task and created an additional 
maintenance task. These are things companies spend a lot of money trying 
to eradicate, so better to avoid them from the outset ;-)

-- 
Cheers,
Marc




More information about the pmwiki-users mailing list