2009/9/8 DaveG <pmw...@solidgone.com>:
> Eemeli Aro wrote:
>> So take a look at the BlogeAuth function near the end of bloge.php [...]
>
> Based on this, I think I have things working pretty well. I've not yet
> tested with the scenario that caused issues, but the basics are working.
> Essentially I do this:
>
> if ( COMMENTING ) {
> #Force read privs for public commenting
> $page = PmWikiAuth($pagename, 'read', $authprompt, $since);
> }else{
> #If not commenting, let default PmWiki authorization take place.
> $page = PmWikiAuth($pagename, $level, $authprompt, $since);
> }
>
> This is simplified a little, and I don't hard-code with a call PmWikiAuth.
> Am I correct in this approach, or have I missed something?
Looks all right. Assuming that you want to give everyone access to
editing all comments, or that COMMENTING has conditions behind it that
really make sure it never happens if $pagename previously exists.
> [1] Also, I was curious from a Bloge perspective, what is the purpose of
> this line, which seems to say "if we don't prompt the user for credentials
> don't allow access" - when would $authprompt be false?
> if (!$authprompt) return FALSE;
$authprompt is false in quite a few calls to RetrieveAuthPage, which
passes that variable to $AuthFunction; a quick grep finds me 12
instances of that happening in the PmWiki core files.
That particular line only happens if the page in question exists, we
would normally have read access to it, but don't have edit access, the
page is in the Blog group, and is either a draft page or has a ctime
that's in the future, and we're trying to just read the page. If all
that is true, then access should be denied, and if $authprompt is
false the return of $AuthFunction should be false, hence we return
false.
> [2] I *think* the purpose of these line is to override the authentication
> levels for the current page. ie, current user has read/edit permissions. Is
> that correct? Thus, subsequent calls to something like CondAuth would return
> read privs.
> $page['=auth']['read'] = 0;
> $page['=passwd']['read'] = $page['=passwd']['edit'];
No, as I said earlier the authentication cache is kept by the wrapped
auth function, eg. PmWikiAuth. and the $page it returns is not a
reference, but a new instance. Hence anything set in BlogeAuth only
affects the then-retrieved $page. Later calls to CondAuth will get an
entirely different $page, at which point authentication is checked
again, just as it should be.
And in fact those particular lines remove read permissions instead of
adding them. The second line is part of what's required to prevent the
page from being pagelisted.
> [3] The way I interpret the code, is Bloge may do multiple calls to
> $BlogeAuthFunction -- possibly as many as three calls. I suspect the logic
> conditions on each would preclude 3 calls, but minimally it will be 2 calls.
> Is there a reason for that?
Trace the code paths; the auth function is ever called at most twice,
and even that is pretty rare. There are three auth function calls in
BlogeAuth:
The first happens if you're trying to edit a comment, in which case we
need to load $page to read its time and host values, so we can let an
anonymous commenter edit their post if they're coming from the same IP
address by changing the $level to 'read'. This could in fact be
replaced by a ReadPage call.
The second always happens.
The third call takes place if you're trying to read a draft or future
blog post to which you don't have edit access and $authprompt is true,
in which case that call will generate the appropriate login screen.
eemeli
_______________________________________________
pmwiki-devel mailing list
pmwiki-devel@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
