Now CKEditor module allows user to choose which security filters to run, before loading content into CKEditor.
I'd actually remove the option of selecting security filters by users in CKEditor profiles.
Executing instead all filters enabled on specific input format, that we are sure that are security filters, should be less complicated from the end user perspective (less things to configure).

#3 D7-Change-security-filters-policy.patch19.64 KBmkesicki
Members fund testing for the Drupal project. Drupal Association Learn more


jcisio’s picture

Is there anyway to know which filters are security filters? Even if we know, we'd use that to make a default configuration in a fieldset in the advanced settings fieldset.

dczepierga’s picture

Yes, in new version u will see in security filters section which filters are whitelisted by us with status for each text format. Also it would be possible to add new security filter by API, and then will be listed there too...

If u add any filter (which is whitelisted) to the text format, the status in security filters section will change and it would be used in filter XSS call.

For now i must fix one bug in CKFinder, and after that i will commit patch with changes for security filters...


mkesicki’s picture

Status: Active » Needs review
19.64 KB

I added patch to this. I tested this and it works fine for me.

dczepierga’s picture

Status: Needs review » Fixed

Changes commited to GIT (diff)


Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

anrikun’s picture

Title: [D7] Change security filters policy » [D7] Changing security filters policy this way might break previous configs
Category: feature » bug
Priority: Normal » Major
Status: Closed (fixed) » Active

Oh no! Why did you change this?
This might break things up on sites using CKEditor SWF with HTML Filter.
See #1561156: Classid not present when editing
Because HTML Filter breaks the classid attribute, it should never be run as a security filter on profiles using CKEditor SWF. But it is fine to run it as a normal filter after editing, because CKEditor SWF Filter fixes the classid attribute back.

The way it worked before allowed to disable HTML Filter as a security filter even when it was enabled in the input format being used.
No it is no longer possible.
What about existing sites? I'm OK that less things to configure might be better for new end users, but you cannot make impossible something that was possible for previous users.

dczepierga’s picture

Title: [D7] Changing security filters policy this way might break previous configs » [D7] Change security filters policy
Category: bug » feature
Priority: Major » Normal
Status: Active » Closed (fixed)

First of all pls not open closed issue - if u have any problems open new issue with it!

If HTML Filter break something it should be fixed in this filter module, not in CKEditor module - we cannot do anything with bugs in Drupal core module...

If u really want to fix it in CKEditor module u can try to add this filter as security filter in CKEditor module:

function MODULENAME_ckeditor_security_filter() {
    return array(
        'security_filter_name' => array(
            // Security filter title - it would be displayed in the "Security > Security filters" section of profile settings.
            'title' => t('Security filter title'),
            // Security filter description - it would be displayed in the "Security > Security filters" section of profile settings.
            'description' => t('Security filter description'),

Everything is written about this in README.txt file.

If u have more questions pls open new issue with this problem.