• View
• Edit
• History
• Attach
• Print

01242

Description: In testing 2.2.21, things looked fine for me, then I accepted the 2.2.22, cleared caches and cookies in IE8 and FF3 and now all my wiki pages are wide open to the world for editing, no authentication necessary. Please fix this fast or put the 2.2.21 "latest" back on the download site.

Update: Ok...I have found I can revert to the previous method by using $EnablePageVarAuth = 0; So I can move forward, but I do not agree that the upgrade should be made in this way. Until we all have time to read documentation? about this new method and what it entails, I believe the $EnablePageVarAuth = 0; should be added as part of the upgrade, so that by default all protected pages are not automatically open to the world.

If documentation exists about this new method, please point us to it. Thanks.

This should be an awesome bug. I released 2.2.23 defaulting $EnablePageVarAuth to 0 until I investigate it.

Unfortunately, I am unable to reproduce this bug. Could you detail what types of password protection are you using? ($DefaultPasswords, Page attributes passwords, GroupAttributes passwords, AuthUser,...) Thanks! --Petko January 25, 2011, at 03:15 PM

Related entry: PITS:01213 (PageVar() should respect authentications)

No problem. I was just using:

$DefaultPasswords['admin'] = crypt('someadminpassword');
$DefaultPasswords['edit'] = crypt('someeditpassword');

in my config. After the upgrade and until I set $EnablePageVarAuth to 0, I could get into all pages to edit, even after clearing cookies. I was no longer prompted for any password. Testing in IE8 and FF3.

Thanks again for your report. Even if I couldn't reproduce the bug, the 2.2.22 version cached a wrong page metadata, and it is very likely that in some cases this can cause such problems and more. This should be fixed in 2.2.23, and from 2.2.24 on, we'll have a different way to do what we want, if an administrator enables it. --Petko February 06, 2011, at 03:58 AM