[pmwiki-users] Uninstalling EProtect
jo at durchholz.org
Thu Apr 14 10:11:10 CDT 2005
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_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
I'd not even have to respect (:markup:) and such.
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
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?
More information about the pmwiki-users