[pmwiki-devel] Reading the page, and forcing a re-read

[DaveG]

Eemeli Aro wrote:
> 2009/9/8 DaveG <pmwiki at solidgone.com>:
> Bloge uses PmForm for posting comments. Each comment is kept as a
> separate page in a common group Comments, and hence limits the scope
> of what needs to be at all modifiable by anonymous users. PmForm also
> forces you to define in PHP a specific form target, which mitigates
> the possibility of someone maliciously altering what the form does.
This is the same approach BlogIt uses. I use PmForms to capture 
comments, and each comment is stored in a separate page, within a single 
group, using a specific page-naming format. So after resetting the Edit 
password, I basically let PmForm manage the page write process.

What is a little odd is that in only a very few cases does this approach 
not work. Most installations appear to work fine. A few have a lot of 
problems with being prompted for edit passwords when posting comments. 
The best I can determine is that page reads (like from CondAuth) are 
causing the problem.


> Now, all that needs to be permitted is 'edit' or 'publish' access to
> pages in the comment group when using the action 'pmform', which I've
> done by defining a wrapper function around $AuthFunction (by default,
> PmWikiAuth) which is called by RetrieveAuthPage, which is what eg.
> CondAuth uses internally. It's this $AuthFunction that's maintaining
> any cache of authorization permissions, hence a wrapper around it
> isn't bothered by any previous page reads.

> Now, the way RetrieveAuthPage is used almost always (including PmForm)
> is by calling it with a page name and a level of authorization that
> should be checked, and if the return is false that means authorization
> has been denied, otherwise the return is the requested page. What my
> wrapper does is before calling $AuthFunction it checks for a specific
> set of conditions and if those match, it calls $AuthFunction for the
> comment page in question using 'read' permission instead.
Understood. So if I create a wrapper for the $AuthFunction and call 
PmWikiAuth with 'read' level for comments, and do a 'normal' call for 
other occurrences, that sounds like it will handle anon comments.

I presume one of the requirements is explicitly creating Edit 
permissions on the Comment group?


> So take a look at the BlogeAuth function near the end of bloge.php for
> a possible answer. The other stuff that BlogeAuth does allows for
> anonymous users to edit their comments for up to half an hour from
> their last edit and 


> helps hide blog posts that are drafts or with
> future create dates from being seen by anonymous users. The really
> tricky part is keeping those pages from showing up in pagelists, which
> maintain their own cache that uses RetrieveAuthPage slightly
> differently from everything else.
Yes, this is something I have not yet tackled in BlogIt...