[pmwiki-users] PmWikiAuth questions

SteP 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 mailing list