[pmwiki-users] Uninstalling EProtect

[Patrick R. Michaud]

On Thu, Apr 14, 2005 at 02:25:48PM +0200, Joachim Durchholz wrote:
> >Probably yes -- $EditFunctions is the list of things to be done 
> >in the edit/restore/save/preview sequence.
> 
> Well, of course it still does make sense - the functions listed in 
> $EditFunctions know when they are expected to do something. But if 
> there's a new action that reads or writes the page store, I'd have to 
> upgrade the edit function to properly handle that action as well. Seems 
> redundant for a function that just wants to be called when data is read 
> from the page store.

In general the $EditFunctions shouldn't be reading from or saving to
the page store directly -- they simply manipulate the page (that has
already been loaded from the edit form) to prepare it for posting
or preview.

> Also, there's a "source" action that doesn't go through $EditFunctions. 
> If a spammer finds a link with a query string of "?action=source", he'd 
> get the cleartext mail addresses. The appropriate place for the 
> translation would be something that's called by ?action=source, probably 
> ReadPage. (Unfortunately, ReadPage doesn't have any hooks.)

ReadPage has hooks -- just generate a custom PageStore class that
does any translations you want when the file is read (or written).

> Oh, and for symmetry, the reverse transformation would then have to be 
> done in WritePage, not with a $ROSPattern. But that's just a detail :-)

And the custom PageStore class can do the reverse transformation.  :-)

> The question of the day being: where in the sequence of the 
> EditFunctions do I insert the mail munging stuff? 

I dunno without knowing a bit more of how you're doing it.  But
inserting in the middle isn't so hard-- use PHP's array_search()
and array_splice() functions.  For example, to insert something
immediately before 'RestorePage':

    array_splice($EditFunctions, 
        array_search($EditFunctions, 'RestorePage'), 
        0, array('Something'));

> Consider the following scenario:
> 
> 1. User begins to edit a page with mail addresses. He is shown 
> obfuscated mail addresses (not that this bothers him).
> 2. Wiki administrator changes the obfuscation encoding.
> 3. User finishes his edits and saves his changes. PmWiki now tries to 
> unobfuscate the mail addresses with the changed encoding, garbling the 
> mail addresses beyond recognition.
> 
> So PmWiki needs to get the initial obfuscation key back together with 
> the edited input field. Technically easy, since that's exactly the kind 
> of task that hidden input fields were designed for, but what's the best 
> place in PmWiki to make it emit that hidden field?

Make the obfuscation key part of the encoded mail addresses.  
When decoding an address, always use the key that is part of the encoded
address; when encoding an address, always use the wiki-administrator
supplied key.

Pm