01490: Save/Cancel after page edit causes "internal server error" depending on page content
Description: For numerous pages in my wiki, after editing, when selecting "Save" *or even "Cancel"*, I get "server encountered an internal error or misconfiguration". However, whether save/cancel succeeds seems to depend on the actual content of the page at the time I click save/cancel, and consistently so, i.e., the same content leads to the same behavior, which is rather bizarre.
I have isolated this issue into a very small example at the following page: https://david-kempe.com/contest/pmwiki.php/Main/PracticeProblemCopy
This page allows edits without passwords, so others can try. Notice that it says "needs get to". If you replace this with "needs to get" (and change nothing else), it causes a server error. However, various other edits (e.g., adding other paragraphs, or some spaces) do not.
I am using the 'maguila' skin as part of the whole site, but the same issue occurs with the 'pmwiki' skin, so I doubt the skin is the culprit. The only changes I made to the pmwiki.php file is to add logging (and I fixed a few warnings in maguila.php). No errors are written in the logs when this happens.
I can't really imagine that having server errors depending on the specific content of a page is desired, so I assume there's a bug somewhere (maybe some misused memory?) Unfortunately, I have no PHP programming experience, so do not know how to debug this.
Thank you in advance for any help! David Kempe
This is very likely caused by the web application firewall on the server, see Troubleshooting#mod_security. It is not "to get" that causes the problem, but "get org", and you can place the null-space escape markup to break it and push it through:
get [==] organized |
There is not much else we can do since the posted request is blocked before reaching PmWiki. We have this recipe Cookbook:EncodePost that kind of works but I find the flashing of the encoded text very annoying, and I haven't had the time and peace to work around it. :-/ --Petko
So I rewrote Cookbook:EncodePost to make it less annoying. Feel free to try it and please report any problems. --Petko
Thank you, Petko, for getting so quickly to this, and putting in all the effort to fix this (for me and others). Much appreciated! I tried it out, including changing the encoding to UTF-8 (after converting the entire Wiki to UTF-8 first, per instructions), then following the instructions for EncodePost. Now, I get "Error, Token invalid or missing". It seems like this error is thrown in the new function when pmtoken(1) returns false. Sorry to bother you (in particular if this was just some stupid error on my part), but what is the likely cause? Some misconfiguration in config.php? Something else? Thanks again! --David Kempe @2023-05-02.
It doesn't bother me at all! :-) It looks as if the edit form was missing the pmtoken element, were you trying pmwiki.php from the nightly release and hadn't updated scripts/forms.php? Because it works at Cookbook:EncodePost. You can disable the new token feature by setting in config.php $EnablePmToken = 0; Otherwise, I have just released PmWiki 2.3.23 - I'd be interested if you can report problems with it. --Petko
Thank you again! After upgrading to 2.3.23, everything seems to work now. :) I had not tried a nightly release - just 2.3.22 "out of the box" with the new Cookbook:EncodePost. But it's great that this seems to solve the problem. David Kempe @2023-05-03.
Thanks - indeed the new EncodePost version did require the refactored pmtoken() from the nightly or 2.2.23, and would cause an error in older versions. Now added to the recipe page as requirement. --Petko