[Pmwiki-users] PmWiki password puzzles

Knut Alboldt mailing
Tue Aug 31 00:40:17 CDT 2004


At 14:57 30.08.2004, Pm wrote:
>This message talks a bit more about PmWiki's passwording system, and
>has two questions ("Q1" and "Q2" below) on which I'm seeking input.
>For purposes of this message, I'm temporarily setting aside the issue
>of user-based authorization schemes, which I'm also working on.
>
>PmWiki's authentication system has a couple of annoyances that
>I'd like to address.  First, for historical reasons PmWiki's
>default authentication mechanism has been to use HTTP based
>authentication.  Unfortunately, this tends to work only in
>environments where PHP has been built as an Apache module;
>i.e., it generally doesn't work if PHP is running as a CGI script or
>other environments where the HTTP authentication information is not
>available to PHP.  It also fails on systems where the PmWiki script
>is being otherwise protected by Apache (e.g., a .htaccess file).

I'm using Win2K, Apache 1.3.27 and PHP 4.3.5 running not as mod_php (so it 
must be running as CGI I think) and I thought I can't read the 
password-prtected pages copied from my online-linux-site because of 
different cryption (md5 / crypt). So that's the real reason ! Now I understand.


>The solution to this second problem has typically been to use session-based
>authentication, via the sessionauth.php script.  However, since
>session-based authentication works "everywhere", while HTTP Basic
>authentication works only on selected systems, I'm thinking I should
>just switch the distribution to use session-based authentication
>by default and provide HTTP Basic authentication as an option.  I think
>would eliminate a lot of frustration and mail from people who are
>having trouble getting passwords to work on their systems.
>
>*** Q1: Any one have comments in favor of or against switching to 
>session-based
>authentication as the default?

I don't know much about session handlinh in php, but don't you have to 
switch cookies on, otherwise the URL will get added by the session-id or so 
? If the session-id is appended (i.e. you switched cookies off), is it 
possible to simply save the pages url in a bookmark to call the page again 
? I quess if the bookmarks is saved with that session-id, the next call 
will fail, cause the session-id is'nt valid, right ? I think, bookmarking 
pages of a wiki, even if read or write-protected is a common think, so it 
should run with the implemented. And a user should not be forced to switch 
javascript or cookies on to use pmwiki. I like pmwiki, cause it's running 
save for the user, cause he can switch java, javascript and cookies off.

If this all is no problem, I think session-based as a default would be ok.


>Second, in response to John Rankin's earlier message (and to better support
>user-based authorization) I'm changing the authentication system
>so that a page can have multiple passwords for each access level.
>However, there's still an annoyance with pages that have both a read
>and an edit password set-- an author editing such a page has to alternate
>between entering the edit and the read password at each post, which
>is annoying.  We can "solve" this annoyance by either:
>   1. Leave things as they are--someone wanting to avoid the alternating
>      edit+read password problem in pages would then set the edit password
>      in both the edit and read password fields.
>   2. Have the system assume that a person who knows the edit or
>      attribute password is automatically given read permission to a page
>      without having to explicitly enter or know the read password.
>   3. Have the system cache all of the passwords that have been entered
>      during a browser session, and test each page request against the
>      set of passwords (so that a user would only have to enter each
>      unique password once per browsing session).
>
>#1 has the advantage of a simpler implementation (not important) and
>preserving the ability to force authors to be aware of the separate
>read+edit passwords; the disadvantage is that a person setting a password
>has to know to enter the edit password in both the "read" and "edit"
>password fields.
>
>#2 has the advantage of handling a great many things automatically, with
>the possible disadvantage that it's not possible give someone the ability
>to edit or change a page's attributes without also giving read permission
>(probably not common).
>
>#3 has the advantage of being able to automatically keep track of all the
>passwords an author has used during a session, greatly reducing the number
>of password prompts encountered; but there may be a disadvantage in it
>becoming "too seamless" so that authors forget which pages are protected
>where.
>
>#2 and #3 above are probably not mutually exclusive, so they can
>both be implemented or made as options that can be enabled or disabled.
>
>*** Q2:  But my question is, what should be PmWiki's "default" setup
>in the distributed version?

#2 and #3
what's about cascading the access rights:
attrib-pw => can change attribs, view-diff, edit and read
edit-pw => can edit, view diffs + read
diff-pw => view diffs + read
read-pw => can read
no-pw => can do all actions

Knut 




More information about the pmwiki-users mailing list