[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"
link.
- 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
both.
> > 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;
[snip]
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
with.
Bronwyn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20051123/7dc15cd4/attachment.html
More information about the pmwiki-users
mailing list