01284: status 412 when restoring an old edit

Summary: status 412 when restoring an old edit
Created: 2012-03-30 22:38
Status: Closed
Category: Bug
From: CarlosAB
Assigned:
Priority: 3
Version: 2.2.36 (VersionNum=2002036).
OS: linux/apache

Description: I'm getting a status 412 everytime I try to restore the last change.

Here is the link:

http://codex.wiki.br/Tutoriais/ComoSalvarOuBaixarV%C3%ADdeosRtmpeAdobeFlashFlvMp4FmsDeQualquerSiteQuePermita?action=edit&restore=diff:1333164230:1333124081:&preview=y

This definitely is not something done by PmWiki. It appears that you cannot post any page that contains the percent "%" sign. This may come from an incorrectly configured Apache module called mod_security (typically trying too hard to prevent XSS attacks, see Troubleshooting#mod_security, [1] [2] [3]). You should talk to your hosting provider or try to find some documentation about how this can be fixed. --Petko March 31, 2012, at 03:42 AM

I have contacted the hosting company, let's see what happens. CarlosAB March 31, 2012, at 03:59 AM


The problem was solved for a while, I talked with the admin, but now it is bugging me again. :/ . I wonder if there is a way to encrypt the content inside the textarea to be sent to the server, that will not trigger any mod_security rules, so I don't have to keep a long conversation with admins, otherwise we will start to tell each other the story of our lives. :) Is there any recipe for it? Perhaps use javascript to encrypt the text using base_64 on the client side, and a way to decrypt on the server side, before use.

Now the problem seems to be the use of <iframe or &lt;iframe but you could use [=<=]iframe or <[==]iframe to evade the filters. Creating a recipe that encrypts or encodes the content client-side and decodes it server-side is probably possible but it should encode all text(area) fields in the submitted form. --Petko July 06, 2012, at 08:48 AM

I tried everything : &lt;iframe , &lt;iframe&gt; , [=<=]iframe , [=<=]iframe[=>=] , <[==]iframe , <[==]iframe[==]> . I have even tried stuff I know that wouldn't do anything, also to no avail. I should have remembered the trick you teached me before in another PITS entry, but I got frustrated after losing 3 translated articles in a row. Last resort! Tell my sad story to the admin and see what happens. Thank you for your time and patience Petko. CarlosAB July 06, 2012, at 07:52 PM

Really no problem, I like stories. :-) You should be able to restore the articles from the history, after isolating and escaping the problematic code. I copied all text from the linked page, pasted it into your WikiSandbox. Then I pressed "Preview" (it broke) then pressed Back, removed a part of the pasted text, and again Preview+Back+Remove until it didn't break. Then I looked what in the removed part could have caused it to break. (You could also add paragraphs until it breaks.) If <[==]iframe doesn't fix the page, you may have another <iframe or something else in the wikitext that breaks it, and you can find it the same way, isolating paragraphs. The percent character doesn't seem to cause that problem on your WikiSandbox. --Petko July 06, 2012, at 09:37 PM

Well, since I know you better than my server admin, here it goes: Once upon a time there was this little boy named Carlos ... :-) Kidding. Well, I'm not restoring an article anymore as the begining of this PITS entry suggests, I'm just writing articles now, but I believe the same method could be applied as I have used it before, just as you described. I'm gonna try this before talking to the server admin. I hope you don't mind or in anyway get offended with my attempts to make small jokes in english. I do it just to keep the spirit up. :-) Once again, thank you. CarlosAB July 06, 2012, at 10:05 PM

This markup was the culprit -> %red%Deprecado%% and the <iframe> tag . I think I'm gonna close this . CarlosAB July 06, 2012, at 10:45 PM

The characters %De seem to cause the problem, %red% Deprecado %% with a space between "%" and "De" works. --Petko July 07, 2012, at 03:43 AM