[pmwiki-users] Uninstalling EProtect

[Joachim Durchholz]

Patrick R. Michaud wrote:

> On Thu, Apr 14, 2005 at 12:02:40AM +0200, Joachim Durchholz wrote:
>>>   $ROSPattern['/hidden-email:(\\S+)/e'] = "'mailto:'.str_rot13('$1')";
>>
>> Er... what's a $ROSPattern?
> 
> It's a "Replace on Save" pattern -- a set of pattern->replacements to
> be peformed on the markup text just before the page is saved.
> (In particular, this is how the author.php script is able to convert
> "~~~" into an author's name when the page is saved.)

Ah, good to have that! That simplifies the design for the "write to page 
store" part considerably.

>> However, I think it would be better if the links were converted to 
>> hidden-email: links when loading from the page store, and converted
>> by to mailto: links when saving.
>> 
>> What's the best way to hook that up? (eProtect munges the
>> $EditFunctions array - is that the right place?)
> 
> Probably yes -- $EditFunctions is the list of things to be done 
> in the edit/restore/save/preview sequence.

Hmm... this is puzzling me.

 From reading the sources in pmwiki.php, it seems that all the functions 
are called in order, regardless of whether the current action is "edit", 
"post", or whatever. But that doesn't make sense! The "RestorePage" 
function shouldn't be called in "edit", "save", or "preview".

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.

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.)

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 :-)


Well, I guess for now it's $EditFunctions and $ROSPattern regardless.

The question of the day being: where in the sequence of the 
EditFunctions do I insert the mail munging stuff? My wiki tells me this 
sequence of activities:
     [EditFunctions] => Array
         (
             [0] => MergeSimulEdits
             [1] => RequireAuthor
             [2] => EditTemplate
             [3] => RestorePage
             [4] => ReplaceOnSave
             [5] => SaveAttributes
             [6] => PostPage
             [7] => PostRecentChanges
             [8] => PreviewPage
         )
I'd prefer it either at the beginning or the end of the sequence (that's 
easiest technically, inserting into the middle of an array seems to be 
rather difficult if the existing eProtect code is any indication). 
However, if some other place would be better, I'd do it anyway - it's 
not *that* hard to do.

>> Besides, I'm working on a new version of eProtect where the wiki
>> admin can specify arbitrary encodings, so even a browser with a
>> rot13 facility won't be of much help anymore :-))
> 
> Cool.

I have a slight problem with that.

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?
(No real inefficiencies involved with that BTW: the JavaScript needs the 
(un)obfuscation key anyway, and it can pick it off the hidden input 
field instead of carrying it as a string constant.)

Regards,
Jo