[pmwiki-devel] Advice needed for CondAuth and cookbook sequencing

[Petko Yotov]

On Thursday 18 February 2010 01:58:42, DaveG wrote :
> Both Drafts and BlogIt call functions which basically populate the
> password/authorization cache, effectively locking in the privs set at
> that point. (Drafts calls CondAuth, and BlogIt makes a call to
> PageTextVar.) This means that it is not possible to use both BlogIt and
> Drafts.
> 
> A workable solution would be to selectively enable either Drafts or
> BlogIt, and not enable both at once. This is reasonable, but often the
> check seems to involve a call to a 'caching' function (CondAuth to check
> if a user has Edit permissions for example), which leads back to the
> original problem.
> 
> Short-term workaround: In my experience calls to CondAuth() (and thus
> RetrieveAuthPage() and then PmWikiAuth()) tend to be the cause of these
> kinds of problems.

Both CondAuth() and PageTextVar() call RetrieveAuthPage() so both are the 
cause of the problems.

These functions should be first called after all possible configurations had 
been defined, set and fixed, otherwise indeed, there are often authentication 
or cache problems hard to debug.

I regret that on a number of pages on pmwiki.org, there are instructions to 
call those functions even inside config.php, which may be too early and lead 
to problems.

> Is there perhaps a 'cheap-mans' alternative to
> CondAuth/PmWikiAuth which doesn't do caching? How have others handled
> this kind of thing?

You could get the page with ReadPage() and parse the PageTextVariables with a 
regular expression. If I had to do this to read many PTVs on many pages it 
could require disk files to be opened many times, so I'd likely use an 
alternative global caching variable.

Note that ReadPage does not check permissions, but when you display or include 
the page via PmWiki's functions, permissions should be respected.

There could also be better solutions of which I haven't thought. :-)

> Longer-term: It seems like it would make sense for functions which cache
> operations to accept a parameter disabling the caching operation for
> that call. I haven't looked too much in to the feasibility of this, and
> suspect it would might be a complex change to make, but it would at
> least be transparent to existing code, and provide an option in cases
> where we need to allow subsequent changes to objects.

Yes it would be quite complicated, I'm also not sure if we could do this 
reliably -- we wouldn't know what to do if the page has(n't) already been read 
and cached.


The draft.php script needs to check permissions only when a page is edited 
with ?action=edit so I refactored it and it will no longer call CondAuth() in 
other cases. (Committed to Subversion for 2.2.15, ready to be tested.)

If your script doesn't always need to call PageTextVar(), you might call it 
conditionally. If it can be called not when the script is included but later, 
like from a Markup() function or from $EditFunctions or $FPLTemplateFunctions, 
this would almost certainly fix things.

Petko