On 11/23/05, <b class="gmail_sendername">Patrick R. Michaud</b> <<a href="mailto:pmichaud@pobox.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">pmichaud@pobox.com</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, Nov 23, 2005 at 06:18:07PM -0500, Bronwyn Boltwood wrote:<br>> The authtest site definitely works better than my test sites have --<br>> logging in and out seems to work. (Yes, this is impressive after what I've
<br>> been seeing.) But it's not a representative test yet, since only editing<br>> is passworded.<br><br>OOPS! I commented those out when troubleshooting the "id:*" bug<br>and forgot to uncomment them. It's fixed now.
</blockquote><div><br>
It's okay; we all do that from time to time. :)<br>
<br>
Here's what happened when I played with our test installation some more.<br>
1. edited Site.Login to have text of:<br>
<br>
(:if auth edit:)<br>
%green%Welcome, '''{$Author}'''<br>
(:ifend:)<br>
<br>
(:if auth admin:)<br>
%blue%You have admin rights.<br>
(:ifend:)<br>
<br>
2. set attributes on Site.Login to have read password of id:* and was logged out by system.<br>
3. logged in as bronwyn successfully; logged out.<br>
4. tried to log in as gerry. no welcome message or logout stuff
in sidebar. reload page -- same. went to homepage, and now
I can see that I'm logged in as gerry. <br>
5. went back to login page. no welcome message as there should
be, but not asked for password. logout block in sidebar is gone
again.<br>
6. hit edit. was asked for name and password. gave gerry's
credentials, submitted, page reloads still wanting credentials.
tried bronwyn account just in case. same thing. tried
webmaster and pat accounts; same.<br>
7. went back to homepage; logged out. logged in as pat with same
oddities as described earlier for gerry. edited a few pages
successfully. went back to login page; same behaviour as for
gerry. <br>
8. tried to edit login page; got in with webmaster password. all
seemed well so got out of edit, and page text was displayed as it
should be.<br>
9. logged out and logged in again as bronwyn. login page behaves as expected.<br>
<br>
Contrary to points 4, 5, and 7, I should be getting the welcome message
and other sections wrapped in (:if auth edit:) even as a lowly user,
but I'm not. This is one of the problems I was having with my own
installs. Points 6 and 8 are aggravatingly familiar too..<br>
</div><br>
I wonder how hard it is to have error messages for "bad password and
username combination" and "insufficient rights". They'd be
helpful.<br>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> - The login mechanism can be either:<br>
> - The login script from the cookbook. Its best point is that it<br>> redirects to the page the user was at.<br>> - A read-protected Site.Login
, for id:* or whatever the sitewide edit<br>> password is. Right now, since the attr and admin passwords in your test<br>> site are locked, I can't try making one to see how this works.<br><br>PmWiki 2.1 will have ?action=login available, which will display
<br>Site.AuthForm under the current url. I think I'll do this for<br>2.1.beta4.</blockquote><div><br>
Cool. Not too far away then. Hopefully before I need to give my "how to edit" tutorial? :)<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is there some url redirection taking place in the Apache<br>configuration somewhere...? Redirects tend to play havoc
<br>with posted form values, and that might be why you're never<br>getting past the login form. It might be nothing -- but<br>I'm not sure why Apache is setting REDIRECT values for<br>a url that seems to be already pointing to the correct target.
<br></blockquote></div><br>
I'm not certain, but I have a guess. I have a regular account
with add-on domains (rather than a proper reseller's account), and
grinningfrog is an add-on domain. So that might be causing the
redirects. However, that can't be the only source of my difficulties, because I
had the same problems on localhost, where AFAIK there isn't any
redirection.<br>
<br>
Bronwyn<br>