[pmwiki-users] Uninstalling EProtect

[Joachim Durchholz]

Patrick R. Michaud wrote:

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

Essentially I'm gonna do a search-and-replace much like the markup rules 
do (with a /e option on the regex to call the en/decode function).

In other words, I'll want to find [[mailto:...]] links and replace them 
with [[hidden-email:...]] on read, and the reverse on write.

> 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'));

Well, I've seen that expression in the eprotect sources, and it made my 
eyes (slightly) glaze over.

But I agree that there are infinitely worse things :-)


Overriding the PageStore class sounds tempting. I'd have to go through 
$WikiDir and the $WikiLibDir elements and replace each page store with a 
proxy that wraps the read() and write() functions with encode/decode 
functions.

Hmm......

I'd not even have to respect (:markup:) and such.

Hmm......

Well, [= and =] should be respected anyway. Grmbl.
I'd also need to protect the munged mail addresses from markup 
substitution. I could do my own version of Keep(), but that sounds like 
a pain (we just *might* accidentally generate something that looks like 
PmWik markup).

Well, maybe writing a new PageStore subclass isn't such a good idea then.

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

Hmm... well, that would be quite a lot of data: 104 bytes per email 
address. Multiply that with 10 addresses on a page (say, for a 
participant list after a metting), and you get to sizes that begin to 
make me reconsider.
This could be stripped down to a byte or two, but that would mean that 
rot13 would have to go (even as a corner case of the algorithm).
That would allow a very nifty feature (namely deriving the key from 
$ScriptURL, so different sites would most likely have different keys, 
with no configuration effort for the site admin), but would people mind 
if eProtect will not be configurable for rot13 in the future?

Regards,
Jo