[pmwiki-users] Uninstalling EProtect
jo at durchholz.org
Thu Apr 14 07:25:48 CDT 2005
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
 => MergeSimulEdits
 => RequireAuthor
 => EditTemplate
 => RestorePage
 => ReplaceOnSave
 => SaveAttributes
 => PostPage
 => PostRecentChanges
 => 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 :-))
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?
(un)obfuscation key anyway, and it can pick it off the hidden input
field instead of carrying it as a string constant.)
More information about the pmwiki-users