Summary: passwdattr and passwdedit in files in wikilib.d folder breaks them (Server Error 500)
Created: 2009-06-26 07:24
Status: Closed (fixed 2009-07-07 in the release scripts)
Category: PHP compatibility
OS: SunOS 5.10; Apache/2.2.11 (Unix) mod_fastcgi/2.4.6; PHP 5.2.9
Description: For some time now I encountered a "500 Internal Server Error" accompanied by the beloved "Premature end of script headers"-log file entry whenever I wanted to view some pages in my PmWiki-installation. The most important of them was "PmWiki/DocumentationIndex". I contacted my Hosting Service, tried setting permissions, reconfigured PmWiki, reinstalled PmWiki and all the usual stuff until I finally figured it out.
The problem is caused by the lines "passwdattr=*some_hash*" and "passwdedit=*some_hash*"
in some files inside the wikilib.d folder, which are included in the DocumentationIndex via
These two lines somehow break some script, witch exits silently (due to some build in access violation?) and these pages (and any pages which include them) can't be displayed (Error 500...). I manually removed them and now anything works fine. I don't know if they are needed in the documentation shipped with PmWiki and imagine they are left over from edits to this site here. I would like to either get the underlying issue fixed or see them striped out the next release.
This means that you probably cannot set any password on any page or WikiGroup. Or can you? Is there a 500 error when you access directly such a page (read, edit, history...)? Some pages in the default installation may be semi-protected if they have been subject to vandalism on pmwiki.org. There is also the SiteAdmin group which is locked both for reading and editing, and the Site group which is read-only. --Petko June 27, 2009, at 02:32 AM
I tried what you asked:
Setting passwords works as expected on single pages and on a WikiGroup.
By "read" you mean the normal display by going to the site using the URL without any additional parameters, right?
For pages which include a page which has the pages which have "passwdattr=*some_hash*" can't be read, but can be edited and display the history, if I manually add ?action=edit / ?action=diff to the URL.
The pages which have "passwdattr=*some_hash*"/"passwdedit=*some_hash*" themselves can neither be read, edited or display the history.
"SiteAdmin/SiteAdmin", "SiteAdmin/AuthUser", "SiteAdmin/GroupAttributes" and "SiteAdmin/Status" work, "SiteAdmin/AuthList" breaks with error 500.
"Site/PageListTemplates" breaks, anything else in Site-Group works. I don't know why "SiteAdmin/AuthList" and "Site/PageListTemplates" break.
Hello. I suspect that your PHP installation might be missing some required function like crypt() but I see no way to check this. Can you open
I suspect the output should be the similar on all PmWiki-Sites, right? The form works and doesn't fail visibly, but it creates a very different output.
I used "test" as input. On my installation one result is "K4t3y/ev31QBw", here it is "$1$MsqLeA4X$85gUQqSGn2FLMPqK92x8p0". Both are changing on every re-submit.
Is there anything in phpinfo() which could be useful?Your PHP installation seems to use a different encryption algorithm, and it probably cannot decrypt passwords with the default one. I'll try to find some time to look into it further, but for the moment, here are all pages containing passwords:
PmWiki.AuthUser PmWiki.InitialSetupTasks PmWiki.LinkVariables PmWiki.MailingLists Site.GroupAttributes Site.AuthUser Site.SideBar SiteAdmin.GroupAttributes
You may want to manually remove the
PmWiki.AuthUser PmWiki.InitialSetupTasks PmWiki.LinkVariables PmWiki.MailingLists
I also checked php.net about crypt() for a possible answer and I found the underlying problem!
I turns out php's internal "CRYPT_STD_DES"- and "CRYPT_BLOWFISH"-variables are 1, but only CRYPT_STD_DES is supported!
From phpinfo() I can gather that the mcrypt-extension is installed, may be it could be involved in some sort of workaround.
I don't know if there is anything which could be improved in PmWiki to avoid such situations, but it seems not to be its fault at all.
Thank you for your help. If you need any additional information I try to get it.
The "technical support" from my hosting company is confident that its a PHP-error, as they don't apply patches. They also say I have to buy a root-server, because I could change php/php-config if I want to. As I can't debug the server (to figure out if its PHP or the servers blowfish-backend) and don't need a root-server for my small site I have to rest this case.
It would be nice if the
Thank you again