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)? _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
