Name of a textarea field causing 403/404 on save when relative link included

[iank]

Here's a weird one:

I'm working on a project at the moment that has several TextareaLanguage fields (setup with CKEditor)  The field names are a little inconsistent, but they are as follows:

• body
• richtext
• richtext2
• richtext_boxout
• rtsummary
• rtfooter
• notes

They're not exactly the same, but some have been cloned from others.  However, it seems the naming of the field affects the saving of the page when a relative link is added in the content.  (Absolute or fully-qualified links are fine).  Relative links are the only thing that causes this problem, and in a reproducible manner.

The last three (rtsummary, rtfooter and notes) will not accept a relative link in the content.  Depending on which server I run this on, I either get an immediate 403 Forbidden message, or a 404 Not found when I try to save.  

However, if I rename the fields (for example rtsummary => richtext_summary, rtfooter => richtext_footer and notes to richtext_notes).  Saving the content with a relative link is fine.  If I rename them back, the problem occurs again.

I thought it may have been something in say, mod_security, but if that's the case, why would changing the field name allow the content through?  And why are fully-qualified links accepted, but relative links not?

I can't get my head around it.  

Also, I tried this with a single language textarea field too, with the same results.  I found that for example, the following names don't work:  notes, rtnotes, rt_notes, r_tnotes, and yet richtext_notes is fine.  

Environment is:  PW 3.0.98, PHP 7.030.  There are quite a few modules installed, but I haven't tried disabling them or trying this on a vanilla PW install.  I can get around the issue by renaming the fields, but it would be good to get any suggestions!

No errors are showing in Tracy Debugger.

Thanks,

Ian.

[BitPoet]

18 minutes ago, iank said:

I thought it may have been something in say, mod_security, but if that's the case, why would changing the field name allow the content through?  And why are fully-qualified links accepted, but relative links not?

If you use mod_security with a CMS it isn't specifically aimed at, this is exactly the kind of nonsensical errors you will get since its pattern matches will only make sense in the context of that CMS (mostly WP). Even with a supported CMS you will likely encounter that kind of error if you build a complex, dynamic site or use less popular plugins, and you will have to adapt the rule sets.

I'm pretty sure you'll find log entries from mod_security that match your 403s and 404s.

[iank]

@BitPoet  Thanks - that would make sense I guess.  I don't know if mod_security is present, but I don't think I would have access to the logs;  I'll make some enquiries of the hosting people.

Cheers,

[adrian]

23 hours ago, iank said:

I don't know if mod_security is present

Check the Versions List section of the PW Info panel in Tracy:

[iank]

Thanks @adrian.  Here's what I see:  Does this mean mod_security is not running?

 

[adrian]

3 hours ago, iank said:

Thanks @adrian.  Here's what I see:  Does this mean mod_security is not running?

Hi @iank - it means that it is most likely not running, but if you don't see the *confirmed off then it's not definite. It depends on how PHP is running - whether it's an apache module or not. In this case to be certain you should ssh into the server and type either: httpd -M or apache2 -M and see if it's listed.