[pmwiki-users] PageList Project

[marc]

The Editor said...
> On 1/28/07, marc <gmane at auxbuss.com> wrote:
> > 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?
> 
> Well perhaps nt much.  But I do delete these pages after the time
> limit so I don't have a bunch of these temp pages filling my wiki.

Bah! Extra admin. Be gone ;-)

> I
> also thought it might be more secure putting a time limit on them,
> that they would be less likely to get into the wrong hands--but I
> suppose that's not a big issue.

Exactly. The update email address confirmation link is sent to the 
original email address, and the new email cannot be changed in the link. 
So, unless someone has access to someone's email account, there's no 
risk associated with the confirmation link being seen. And if the email 
account has been compromised, then all bets are off in any case.
 
> > 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);
> 
> Yes this could be done.  It's a good idea.  Either way.  I'll think
> about it some more. It would be easy enough to do either with ZAP
> though I don't have a built in ZAP command, so that's another slight
> advantage to a non-hash approach.

I have an object (or two) and it does all of that for any data plus 
maintains a history that is stored on email, db or wiki page depending 
on the usual admin settings - the same audit trail that can be used by 
any object :-)

In general, I think that's why some of us don't use Zap. It's much 
easier to keep general functionality outside of recipes - loosely 
coupled - rather than within. That way, the functionality can be used 
more broadly and can easily be swapped in and out (strategy, facade and 
factory patterns, amongst others) or extended (decorators, etc.).

One advantage of a Zap-type approach, as I understand it, is avoiding 
having an explosion of action handlers, but that could be implemented if 
needed. It would make sense for a discrete lump of functionality.

> I would also have to dig in and learn the ins and outs of hashing...

Hashing is very simple (see above). Encrypting is only slightly more 
complicated, and you could do this instead. (In this case, keep in mind 
that you need to maintain a valid URL that can be sent via email.)

But this kind of makes my point: that it would be more fruitful for us 
recipe writers to write loosely coupled functionality - obviously I 
prefer objects. We could then exploit each other's code at a slightly 
lower level, that, because of encapsulation, would be simple to use - 
because knowledge of the implementation is not required. I can dream :-)

-- 
Cheers,
Marc