The introduction of EE 2.5 has brought with it some problems thanks to it's extra XSS filtering rules.  Whilst important for security, it can cause some headaches for site admins using SafeCracker to submit & edit content.  Thankfully it's easy to override the filtering for certain field IDs, and even for types of field.

I discovered this problem when working in the excellent Wygwam WYSIWYG editor (based on CKeditor).  Wygwam has it's own file management system which makes it easy to add images into an article, however, I was finding large chunks of my HTML were getting trashed upon saving, when the article contained more than one image.

It took a lot of retrying and examining the rendered code to see what was happening.  Basically, when adding an image to an article via Wygwam's file manager, it adds an inline style for the image's dimensions (not exactly desirable, but there appears to be no choice in the matter).  Upon submitting the article, EE's XSS filter would strip part of the code out.  Where it should read:

<img alt="" src="http://www.website.com/images/1.jpg" style="width: 719px; height: 113px;" />

The final page source looked like this:

<img alt="" src="http://www.website.com/images/1.jpg" 719px; height: 113px;" />

The page rendered ok on the face of it (modern browers cope well with minor errors), but the real problems start when you re-open the article for editing again in SafeCracker: Wygwam was attempting to correct the errors in the HTML, often with disastrous consequences:

<p><img a="" adding="" all="" allowing="" also="" alt="" and="" appointed="" are="" are:="" at=""
backed="" beauty="" becoming="" brand="" breeds="" business="" business.="" by="" commitment=""
company="" confidence="" core="" covering="" currently="" dealt="" develop="" east="" england=""
ensure="" europe="" even="" exclusively="" expanding="" fact="" field="" following="" full=""
full-time="" fully="" greater="" have="" height:="" home="" img="" in="" is="" its="" julie.=""
know="" leads="" maintains="" market="" most="" needs="" north="" obviously="" of="" our=""
own="" paramount="" post-soviet="" potential="" pro="" professional="" professionals=""
qualified="" reach="" recruited="" represent="" requirements="" right="" sales="" salon=""
salon.="" sam.="" src="http://www.website.co.uk/images/image.jpg" staff="" state="" statement=""
steadily="" still="" success="" supportive="" team="" territories:="" the="" their=""
therapists="" they="" this="" through="" throughout="" to="" trainers="" training="" uk=""
uk.="" ultimately="" up="" we="" when="" whilst="" who="" whole="" will="" with="" year=""
your="" /></p>

Disabling XSS Filtering

Thankfully this problem has been partially addressed in EE – hopefully this will be developed further into some working SafeCracker parameters at some point in the future, but for now a core file modification is the only way around it.

REMEMBER: Always backup your website before making any core changes to your files!

You can disable the XSS filter globally for a set of defined field types, or specify individual field IDs if preferred.  If you are using SafeCracker to allow public entry where they is a potential security risk, I recommend specifying individual field IDs so that you can target just your admin SafeCracker forms.

First, you'll need to open the following file on your server for editing:

/system/expressionengine/modules/safecracker/libraries/safecracker_lib.php

Now locate line numbers 2572 and 2573 (or around this area) – they should look like this:

$this->skip_xss_fieldtypes = array();
$this->skip_xss_field_ids = array();

If you want to disable the filter on a whole group of fields, then simply add the field types into the first array, enclosed in inverted commas, and separate each with a comma:

$this->skip_xss_fieldtypes = array('wygwam','textarea');

If you want to disable the filter just for individual field IDs, just add the IDs to the second array in the same way:

$this->skip_xss_field_ids = array('1','5','9');

Now save the file and try your SafeCracker form – you should find that EE leaves your field intact!

References & Further Reading

• SafeCracker and HTML inputs (EE forums)
• My original bug report at Pixel&Tonic
• ExpressionEngine 2.5.0 release notes
• EE Bug Tracker report 16907
• Pixel & Tonic's Wygwam

There are no comments yet.

Have something to say? Join in the conversation!

Leave a comment: