[pmwiki-users] authentication problems (built-in and authuser)

Bronwyn Boltwood arndis at gmail.com
Wed Nov 23 17:18:07 CST 2005

On 11/23/05, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Wed, Nov 23, 2005 at 02:13:11PM -0500, Bronwyn Boltwood wrote:
> > I'm just about ready to defenestrate PmWiki over this.  I've read the
> > documentation several times over, and have spent 5 days or so
> > wrestling with this bloody series of problems.
> Eek, 5 days?!?  Sorry about that.  Let's see what we can figure out.

Don't worry too much. :) (1) I was banging my head against this brick wall
privately, not on the list.  (2) I don't have a specific deadline.  But yes,
I have been getting really really frustrated by it.

> In setting up the test I found that 2.1.beta2 has a bug dealing
> with the "id:*" specification.  Now fixed in 2.1.beta3 (just released),
> and the bug didn't exist in 2.1.beta1 or earlier versions, so that
> can't really explain all of the problems you're having.

It does explain some of them, though. :)

> As far as I can tell, everything is working on the authtest
> site as I would expect it to.  Feel free to test it liberally
> and let me know anything that seems odd.  But lacking that,
> I'm guessing it must be a server setting that is causing the problem.

The authtest site definitely works better than my test sites have -- logging
in and out seems to work. (Yes, this is impressive after what I've been
seeing.)  But it's not a representative test yet, since only editing is
passworded.  Here's what I've been aiming for:
- Visitors see what looks like a normal site, except that there's a "Login"
- Editors, once logged in, have rights to edit, diff, and upload.  Relevant
commands and links are wrapped in (:if auth edit:).
- Admins (me for the forseeable future) have admin and attr rights on top of
regular editing rights, and can see the rename and change attributes
commands, thanks to (:if auth admin:).
- The login mechanism can be either:
    - The login script from the cookbook.  Its best point is that it
redirects to the page the user was at.
    - A read-protected Site.Login, for id:* or whatever the sitewide edit
password is.  Right now, since the attr and admin passwords in your test
site are locked, I can't try making one to see how this works.

Since this is for a very small company, either password or user
authentication should be fine when combined with author tracking.  User
authentication is attractive because it can automatically fill in $Author.
But password authentication combined with a Name field on the login form
that fills in $Author would likely be fine too.  The client, of course,
won't have an opinion until it's certain to cost them money or me time or

> > It keeps changing
> > behaviour slightly -- sometimes it works in one browser, and then
> > later it breaks there too.  Anything but work consistently enough to
> > deliver the site to the client.
> The fact that it's inconsistent makes me wonder if it's a PHP
> sessions problem -- almost as if the sessions are immediately being
> expired or timed out.  I know this problem existed on sourceforge;


I honestly don't know.  It's been maddening, I can tell you that.
Especially when it worked in Firefox and Opera, didn't work in IE <6, and
sort of worked in IE6!  For quite a while I thought it was a skin problem,
not a PmWiki problem...  And now I have a most strange Opera bug, where a
chunk of the screen isn't clickable, which may be the skin.

> > I can't even get things to work with the very vanilla setup of two
> > sitewide passwords -- one for edit and one for admin -- and the
> > read-protected Site.Login page!  Even that way, it insists on having
> > the most privileged password before displaying page content.  Pm,
> > surely this isn't by design?
> Definitely not.

Good.  Because my initial reaction to that was a lot of run-on profanity.
The first time I noticed that behaviour I blamed it on the login script,
because there was no way you would make PmWiki do that.

> Is there a url where we could play with this on one of your servers?
> Or, alternatively, could you run a ?action=phpinfo on one of your
> installations and compare the "session" settings with the ones that
> appear at
http://www.pmichaud.com/sandbox/authtest/pmwiki.php?action=phpinfo ?

Yes; you can find it at http://grinningfrog.com/testing/cpm/pmwiki.php .  I
uncommented the remainder of config.php since it doesn't seem to be causing
the problem.  It's at http://grinningfrog.com/testing/cpm/local/config.php ,
but I'm not sure how to make it display as text.

> We'll definitely figure this one out somehow.

*big relieved sigh*  Thank you so much.  Getting authentication working is
the last thing to do before showing this to the client again, and it's been
delaying things...and frankly, I just want to get this damned thing over

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20051123/7dc15cd4/attachment.html 

More information about the pmwiki-users mailing list