[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