On 11/23/05, Patrick R. Michaud <<a href="mailto:pmichaud@pobox.com">pmichaud@pobox.com</a>> wrote:<br>
> On Wed, Nov 23, 2005 at 02:13:11PM -0500, Bronwyn Boltwood wrote:<br>
> > I'm just about ready to defenestrate PmWiki over this. I've read the<br>
> > documentation several times over, and have spent 5 days or so<br>
> > wrestling with this bloody series of problems.<br>
> <br>
> Eek, 5 days?!? Sorry about that. Let's see what we can figure out.<br>
<br>
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.<br>
<br>
> In setting up the test I found that 2.1.beta2 has a bug dealing<br>
> with the "id:*" specification. Now fixed in 2.1.beta3 (just released),<br>
> and the bug didn't exist in 2.1.beta1 or earlier versions, so that<br>
> can't really explain all of the problems you're having.<br>
<br>
It does explain some of them, though. :)<br>
<br>
> As far as I can tell, everything is working on the authtest<br>
> site as I would expect it to. Feel free to test it liberally<br>
> and let me know anything that seems odd. But lacking that,<br>
> I'm guessing it must be a server setting that is causing the problem.<br>
<br>
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:<br>
- Visitors see what looks like a normal site, except that there's a "Login" link. <br>
- Editors, once logged in, have rights to edit, diff, and upload.
Relevant commands and links are wrapped in (:if auth edit:).<br>
- 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:).<br>
- The login mechanism can be either:<br>
- The login script from the cookbook. Its best point is that it redirects to the page the user was at.<br>
- 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.<br>
<br>
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. <br>
<br>
> > It keeps changing<br>
> > behaviour slightly -- sometimes it works in one browser, and then<br>
> > later it breaks there too. Anything but work consistently enough to<br>
> > deliver the site to the client.<br>
> <br>
> The fact that it's inconsistent makes me wonder if it's a PHP<br>
> sessions problem -- almost as if the sessions are immediately being<br>
> expired or timed out. I know this problem existed on sourceforge;<br>
<br>
[snip]<br>
<br>
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.<br>
<br>
> > I can't even get things to work with the very vanilla setup of two<br>
> > sitewide passwords -- one for edit and one for admin -- and the<br>
> > read-protected Site.Login page! Even that way, it insists on having<br>
> > the most privileged password before displaying page content. Pm,<br>
> > surely this isn't by design?<br>
> <br>
> Definitely not.<br>
<br>
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.<br>
<br>
> Is there a url where we could play with this on one of your servers?<br>
> Or, alternatively, could you run a ?action=phpinfo on one of your<br>
> installations and compare the "session" settings with the ones that<br>
> appear at <a href="http://www.pmichaud.com/sandbox/authtest/pmwiki.php?action=phpinfo">http://www.pmichaud.com/sandbox/authtest/pmwiki.php?action=phpinfo</a> ?<br>
<br>
Yes; you can find it at <a href="http://grinningfrog.com/testing/cpm/pmwiki.php">http://grinningfrog.com/testing/cpm/pmwiki.php</a>
. I uncommented the remainder of config.php since it doesn't seem
to be causing the problem. It's at
<a href="http://grinningfrog.com/testing/cpm/local/config.php">http://grinningfrog.com/testing/cpm/local/config.php</a> , but I'm not sure
how to make it display as text.<br>
<br>
> We'll definitely figure this one out somehow.<br>
<br>
*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.<br>
<br>
Bronwyn<br>