[pmwiki-users] Performance problems with passwords

Tyler Spivey tspivey at pcdesk.net
Sat Oct 22 18:55:03 CDT 2016

On 10/21/2016 1:15 AM, Petko Yotov wrote:
 > I have made a change in subversion that will allow you to skip the
 > checking for the "nopass" password with the next version.

Thanks. That seems to work. Thinking about this a bit more, it might be 
masking an underlying problem. I think passwords are checked when they 
don't need to be.

 > If I understand correctly, one could set to 'nopass'
 > $DefaultPasswords['admin'] or $DefaultPasswords['upload'] to allow
 > anyone to edit everywhere or to upload. But this is probably unneeded on
 > the vast majority of the websites running on PmWiki.

The way I understood it from the documentation was that nopass was used
as an edit password to allow unprotected editing of a page whose group 
had an edit password, or for editing of a group protected by a site 
password, or unprotecting a page otherwise protected by a password.

 > For stats close to the real life usage, you might enable cookies in
 > curl, like most real users will have cookies allowed. The session data
 > for authentication is stored, and the key is send to a browser cookie.

I tried this, with some interesting results. With $AllowPassword = 
false, my page load times went back to what I would expect (55ms or so).
When I edit a page, the expected password hashing is done to verify my 
edit password.
Then when I go back, say to the homepage which has no password, it still 
checks passwords, even when the site, group or page doesn't have a read 
password which needs to be checked.

Not really a problem since I'll most likely end up using a local 
non-password-protected wiki, but still interesting.

More information about the pmwiki-users mailing list