Purifier style tags and data attributes

kevindeleon · October 2021

Adding purifier to Fuel has caused some MAJOR headaches for us. Our content managers are mostly front-end developers and have (up until this point) been able to add style tags, data attributes, etc... as needed.

Is there no workaround to allow for "style" tags or data attributes? I see you can add "data" attributes one by one to a config option...but that would be an absolute nightmare to manage any time someone needs to add a data attribute to a bit of HTML code in our site. Is that really the only way?

As for the "style" tag...from time to time we need to add tags to a page...and now we aren't able to do that. I've turned on HTML.Trusted and CSS.Trusted and still no luck. It allows "script" tags...but not "style" tags.

This 1.5 update has not been bueno.

admin · October 2021

Yeah... Purifier is like that aunt at Thanksgiving... you love her and glad she's there but she can be a bit obnoxious and annoying. I've pushed an "enabled" feature to the config on the dev branch if you wish to essentially revert it to before purifier was being used where it just strips out script tags. It is of course, recommended to keep it enabled.
https://github.com/daylightstudio/FUEL-CMS/commit/3f47caa70d8836247ee3bd48f4aaa99a4e457d4d

Also, I added a "purify" property on the MY_Model (which all other models inherit from in FUEL) that can be set to TRUE (default is FALSE unlike the autoencode_entities) which allows you to be a little more selective per model. You can extend the model and use module overwrites to set that to TRUE:

// fuel/application/models/MY_pagevariables_model.php
require_once(FUEL_PATH.'models/Fuel_pagevariables_model');
MY_pagevariables_model extends Fuel_pagevariables_model {
     public $purify = TRUE;
}

Then in the fuel/application/config/MY_fuel_modules.php:

$config['module_overwrites']['pagevariables']['model_name'] = 'MY_pagevariables_model';

More on module overwrites:
https://docs.getfuelcms.com/modules/simple#overwrites

kevindeleon · October 2021

Yeah....neither is really a great option to be honest. If I just "disable" purifier using the new option, then sure it allows style tags, but then I can't allow script tags. If I use purifiier I can allow script tags using HTML.Trusted or whatever, but now I can't use style tags and have to put exceptions in for every single data attribute we ever want to use...I appreciate the help, but this definitely isn't a doable workaround for us unfortunately

admin · October 2021

The disabled method reverts it to essentially how it was before where it would just disable scripts. Are you needing script tags to be inserted in your input form fields in the CMS? If so, I would recommend putting that logic in your template (which could potentially be toggled on by an input field in the CMS).

kevindeleon · October 2021

As of 1.4.7 we are able to add script tags via our input fields...we essentially have a footer code and header code textarea filed that allows that on an as needed basis for quick fixes, etc. As I said before, our content managers are front end devs and we trust them with that kind of stuff, so it's not a major headache.

With this most recent update (1.5.0) it is stripping both script and style tags from those fields (along with data attributes that we use quite often for various scripts, tracking, etc). If I add HTML.Trusted TRUE to the purifier config -- it allows for script tags, but does not allow for style tags. And we still then have to put in exceptions for all of these various data attributes.

If I use the DEV branch code you mentioned above...and set purifier enabled to FALSE -- then it allows style tags, and we don't have to worry about data attributes and other HTML5 elements, but then it no longer allows script tags.

The issue is we have hundreds of pages and it'd be a bit of a nightmare since we're a small team to have to go through all of those pages and then remove that stuff and move it inside templates or come up with a workaround. Of course we have certain sections that are very specific and most all JS and CSS live in their own files... but we have a few "flexible" controller/templates for quick jobs that allow one of our content managers to basically just spin up a page and put whatever HTML/CSS/JS they need to directly in one "content" textarea for times where we don't have the time to create a controller/view template etc and they need to get something out the door. Some times those pages live longer than we'd like and end up being updated/saved... with these new updates (either one) that could completely break those pages when it starts stripping out tags (script tags, style tags, data attributes that haven't been added, etc) on save.

admin · October 2021

One potential workaround may be to create a safe_htmlentities() function in your fuel/application/helpers/my_helper.php which should overwrite the built-in function but in your case removes the $sanitize section:

/**
 * Safely converts a string's entities without encoding HTML tags and quotes
 *
 * @param   string  string to evaluate
 * @param   boolean determines whether to encode the ampersand or not
 * @param   mixed   determines whether to sanitize the string
 * @return  string
 */
function safe_htmlentities($str, $protect_amp = TRUE, $sanitize = TRUE)
{
    // convert all hex single quotes to numeric ... 
    // this was due to an issue we saw with htmlentities still encoding it's ampersand again'... 
    // but was inconsistent across different environments and versions... not sure the issue
    // may need to look into other hex characters
    $str = str_replace('&#x27;', '&#39;', $str);

    // setup temp markers for existing encoded tag brackets 
    $find = array('&lt;','&gt;');
    $replace = array('__TEMP_LT__','__TEMP_GT__');
    $str = str_replace($find,$replace, $str);

    // encode just &
    if ($protect_amp)
    {
        $str = preg_replace('/&(?![a-z#]+;)/i', '__TEMP_AMP__', $str);
    }

    // safely translate now
    if (version_compare(PHP_VERSION, '5.2.3', '>='))
    {
        //$str = htmlspecialchars($str, ENT_NOQUOTES, 'UTF-8', FALSE);
        $str = htmlentities($str, ENT_NOQUOTES, config_item('charset'), FALSE);
    }
    else
    {
        $str = preg_replace('/&(?!(?:#\d++|[a-z]++);)/ui', '&amp;', $str);
        $str = str_replace(array('<', '>'), array('&lt;', '&gt;'), $str);
    }

    // translate everything back
    $str = str_replace($find, array('<','>'), $str);
    $str = str_replace($replace, $find, $str);
    if ($protect_amp)
    {
        $str = str_replace('__TEMP_AMP__', '&', $str);
    }

    // sanitize
    if ($sanitize)
    {
                /* CAUSES PROBLEMS!
        $CI = &get_instance();
        $CI->load->config('purifier', TRUE);
        if ($CI->config->item('enabled', 'purifier'))
        {
            // Better method
            $str = html_purify($str);
        }
        else
        {
            $str = strip_javascript($str);
        }*/
    }

    return $str;
}

kevindeleon · October 2021

Would this go in the my_helper.php file or the MY_string_helper.php?

admin · October 2021

my_helper.php

kevindeleon · November 2021

Thanks!

EcotypeS · November 2021

Thank you for this! I have been having to go into the database itself to fix embed code (put in by front-end editors) that then gets stripped by the parser. We are in a slightly older version of FuelCMS, but I'm thinking that this will be my guide to having tags make it through.

Howdy, Stranger!

Categories

Purifier style tags and data attributes

Comments