[pmwiki-users] PmWikiAuth questions
step.list+pmwiki at gmail.com
Tue Sep 1 04:44:29 CDT 2009
Due to interaction with the password caching mechanism built into function PmWikiAuth() in pmwiki.php,
recipe BlogIt prompts for an edit password even when no edit password is set.
This isn't a PmWikiAuth or BlogIt fault, I think, it's some mysterious - to me - interaction that I want to
understand and patch in my local configuration file or possibly in BlogIt.
BlogIt uses PmForms+Captcha to post an anonymous comment to a dynamically named Page in group
Comments. Before posting the comment, BlogIt temporarily sets $DefaultPasswords['edit']='' to allow for
editing the comment anonymously, relying on the captcha to block spammers. This approach works for
most BlogIt installations, but it doesn't work for mine. So, after I post the comment I get a password prompt
instead of 'post successful'.
What happens in my case - I traced php code extensively - is that before BlogIt sets the default edit
password to null, something else - who knows what - calls PmWikiAuth() for Comments.Page, and
PmWikiAuth() caches Comments.Page pre-existing passwords, which aren't null. Then BlogIt setting the
default edit password to null has no effect - because the next time PmWikiAuth() is called it looks up the
cached value and thinks that an edit password is set, hence the password prompt.
What is the best way to temporarily clear edit passwords (for a page)? In this case setting
$DefaultPasswords['edit']='' proves not to be enough in all situations.
Is there a way for a recipe to tell PmWikiAuth to not look up its cache, or to clear it, just before resetting
the edit password (of a page)?
More information about the pmwiki-users