Upgrading from 1.2 to 1.4 - Javascript being stripped from textarea on save

edited September 2020 in Bug Reports

I have two textarea fields that are definied in MY_fuel_layouts.php as such

'header_code' => [
    'label' => 'Header Code',
    'type' => 'textarea',
    'class' => 'no_editor'
],
'footer_code' => [
    'label' => 'Footer Code',
    'type' => 'textarea',
    'class' => 'no_editor'
]

The layouts that are using these files have sanitize input set to 'sanitize_input' => array(),

They work fine in 1.2, but when I save the page on 1.4 - it strips all javascript out -- it seems to allow HTML and CSS, but not JS. Is this a new security feature, and if so, can it be overridden. I know it's not great practice to keep JS in fields like this...but I inherited this site and at the moment, don't have much choice. I call myself looking for a solution before posting this...but I'm a bit at a loss.

Comments

  • edited September 2020

    So it looks like I have to add: public $auto_encode_entities = false; to models if I want to use JS in a textarea as of 1.4. Is that correct?

    That's fine with modules...but if I want to use JS in fields in page layouts...then I have to add that to the Pages_model.php as well? If I try adding it to my Pages_model -- which it extends Fuel_pages_model -- it doesn't seem to override as I expected.

    Seems like there should be an easier way to override on a layout by layout (or field by field) basis. Or just override MY_model.php auto_encode_entities property in general.

  • edited September 2020

    There were some recent security updates to prevent the usage of javascript in fields. Could you provide an example of what you are seeing regarding the javascript you are entering in? There may be an alternative way to include that javascript.

  • Honestly, anything in-between <script></script> -- including the tags themselves -- are being stripped out (on save) of the textarea regardless of what I set in "sanitize_input" for the given layout.

    The only way I found to fix it was on a model by model basis (per module model) as I said above (or in our case...just editing the core MY_model.php file and setting auto_encode_entities to FALSE instead of having it defaulted to TRUE because honestly it was a pretty bad break to our site and we needed to get it fixed quickly while waiting to see if there's another answer). I know that's probably a security issue, but it is what it is at this point.

    Including the JS another way (in view files etc) would likely be the better way...but sometimes our front-end folks need add something quickly or for testing and throwing it in one of those fields has been the solution...so re-doing everything at the moment would be pretty impossible.

Sign In or Register to comment.