Hyperactive

Ok this is done and should in theory be safe from XSS attacks, as it's using a combination of textile and the whitelist plugin to protect it. Currently it is available to all users. There are a few questions:

• should it be available to all users? Does this make sense? Keeping in mind that images can be entered in posts if you understand the textile syntax, it may not in fact make sense, especially from a surveillance standpoint.
• what should the default options be in the text editor helper? Block justifying text seems pretty disgusting for example, and should probably be removed as an option.
• is the use of textile smart? It'll mean that the whole database will have textile stuff in it, rather than html, which could be potentially pretty annoying when it comes to doing any kind of upgrade to other software (if that ever happens).

I've changed this again. Using textile would have meant that users would have had the ability to enter images into an article text, for example, and I couldn't live with the surveillance aspects of that.

So, I've stripped out the textile editor helper and started doing some purification of html when content gets saved, basically converting all html content to entities. Then the converted html content gets saved in summary_html and body_html (the entity conversion is destructive so we need the original fields so that the content can still be edited if necessary.

The situation as it now stands is this:

• some html can be entered into content body and summary
• there isn't an easy way to use a "normal" html editor because <p> and <br> tags get stripped.

There is a way around this, which would be to use textile for the body and summary fields, and save the resulting html into body_html and summary_html when the content object gets saved. This gives us the benefits of the textile editor helper without the drawbacks, because images will get stripped when the content is saved.

Anyway, this has been a bit of an odyssey. I'm going to move this one back into the wish list and work on it later, I'm sick of looking at it right now.

Ok, once again I've totally redone this.

The site now uses a combination of white_list, tiny_mce, and sanitize_params plugins to provide HTML editing capabilities while foiling XSS attacks. I hit the site with every attack in the XSS cheat sheet and nothing got through.

This also allowed me to remove the summary_html and body_html fields, trimming down the database.