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

[Eemeli Aro]

2009/9/8 DaveG <pmwiki at solidgone.com>:
> In oder to allow posting of anonymous comments, BlogIt sets the edit
> password to an empty string, when a comment is being posted.
>
> This works fine, until a page read occurs before BlogIt is included.
> This happens frequently without being explicit -- for instance a call to
> CondAuth will perform a page read, and establish authorization rules.
> Recipe users will often do this in config.php. At that point, setting
> the password to "" doesn't have the desired effect since PmWiki has
> already established the authorization levels.
>
> So, is there a way from a recipe to force PmWiki to re-establish the
> authorizations? Or, alternately, is setting the edit password to ""
> simply the wrong approach? (It certainly seems to be fairly restrictive
> in what users can perform before including BlogIt.) If so, what is the
> more robust way?

This isn't a direct answer, but here's how Bloge solves the same
problem using a rather different method:

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.

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.

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.

eemeli