[pmwiki-users] Problem with login after uprading to Pmwiki2.2.0-beta44

[Patrick R. Michaud]

On Mon, Apr 16, 2007 at 02:48:13PM -0400, Jason Frisvold wrote:
> I think I figured out what's going on with authentication and my
> wiki...  Inspired by the beta44 release, I decided to travel back a
> few revs until logins worked again.  It seems that I lost the ability
> to login when beta32 was released.
> 
> Digging further, I think I found the problem.  
> [...]  This line (authuser.php, line 33) :
> 
> $pagename = ResolvePageName($pagename);
> 
> was removed between the two betas.  As of beta 44, that line is still
> missing.  Can you please explain to me what this line does because it
> seems to make logins work perfectly here..  Without it, I can't login
> to the wiki at all.

I've been thinking that might be the problem.  We have a bit of
a chicken-and-egg problem here, I'll try to explain it.

Inside of the authuser.php code, we make a call to FmtPageName()
to convert the $AuthUserPageFmt variable into a true pagename.
This is done in the AuthUserId() function with (line 54):

      $pn = FmtPageName($AuthUserPageFmt, $pagename);

However, FmtPageName() really works only if its passed a valid
pagename.  So, if the page is invoked without a complete pagename, 
as in

    http://www.pmwiki.org/pmwiki.php
    http://www.pmwiki.org/pmwiki.php?n=SomeGroup

then the call to FmtPageName() isn't able to determine the
name of the Site.AuthUser page and so authorization fails.

Prior to beta33, we "solved" this problem by forcing authuser.php
to resolve the pagename before calling AuthUserId(), with the
line you noted:

    $pagename = ResolvePageName($pagename);

The ResolvePageName() will take any pagename fragment and "resolve"
it into a full pagename.  So, a partial page name such as "SomeGroup"
will be resolved into "SomeGroup.SomeGroup", "SomeGroup.HomePage",
"Main.SomeGroup", or whatever is appropriate according to the settings
of $DefaultGroup, $DefaultName, $DefaultPage, and $PagePathFmt.

Unfortunately, a side effect of calling ResolvePageName() is that
it does set these variables (thus any settings of $DefaultName
or $DefaultGroup must occur prior to calling authuser.php), and
in certain circumstances it will issue a redirect to the browser
telling it to reload the page with the correct name.  This is 
where things start to blow up, because people will call authuser.php
prior to setting $DefaultGroup or $DefaultName, and then wonder why
the $DefaultGroup or $DefaultName settings don't have any effect.
Or, the browser gets automatically redirected and the authorization 
request is lost.

It doesn't always work to say "be sure to set $DefaultGroup
or $DefaultName prior to calling authuser.php", because sometimes
authuser.php needs to be called from a farmconfig.php file while
$DefaultGroup and/or $DefaultName needs to be set in a per-wiki
local/config.php .  Plus it's not at all obvious to an administrator
that $DefaultGroup and $DefaultName need to be set before calling
authuser.php.

So, since a lot of people were encountering difficulties with
pagenames being resolved "too early" by authuser.php, I took the
call to ResolvePageName() out of authuser.php in beta33.  But, 
now you're run into a situation where authentication is failing 
because the $pagename variable doesn't hold a valid pagename
(which is why I probably put it into authuser.php in the first place).

So, it's a catch-22 of sorts.  There are a bunch of workarounds,
but I'd rather try to figure out the underlying problem first.

The real question at this point is, when/how is authentication 
being requested on your site such that PmWiki isn't being
given a complete pagename?  If we know that, we might be able to
find a reasonable solution.

Hope this helps,

Pm