Please remove HTMLPurifier for HTML content

[Rimi]

I think it's quite reasonable to assume that anyone who enables HTML content accepts the security risks of allowing HTML and that they strongly do not want HTMLPurifier to mess with their work especially in IP.Content. When people enable HTML in a community they have a reason for doing so and while the security that HTMLPurifier provides is nice, I don't feel that the security is desired or even necessary when an administrator intentionally enables HTML content to be posted. 3.3 handled HTML content perfectly. Running it through HTMLPurifier is obstructive.

http://community.invisionpower.com/index.php?app=ccs&module=pages&section=comments&database=12&record=40348&do=findComment&comment_id=107158

^^The solution Matt posted there is not valid and he knows it. Allowing only IP.Content to bypass HTMLPurifier is also not the solution. I just don't see why you think that any administrator would want their content to be stripped by HTMLPurifier and result in something they didn't intend when the entire point of HTML mode is to allow posting of content which was not initially acessible to them.

http://community.invisionpower.com/index.php?app=ccs&module=pages&section=comments&database=12&record=40348&do=findComment&comment_id=107158

http://community.invisionpower.com/index.php?app=ccs&module=pages&section=comments&database=12&record=40348&do=findComment&comment_id=107160

^^He's completely correct. I won't go into how this has completely ruined things for anyone who uses databases and allows HTML since Matt seems to agree that IP.Content should bypass this.

[Marcher Technologies]

:sad: I had to revert 5 boards to pre-upgrade today. This also affects a couple apps I have that the admin is the only one to touch it(ACP) or there is an allowance specific config for it for frontend, I expect HTML and set the editor for it. Apologies for my wording, but this is not a happy camper at the moment.

[Dmacleo]

I am beginning to think this is hitting me too. where the feed blocks pull links and some use images would the html issue be a factor?

I am wondering because whats shown in acp block design template does not match what the board actually displays.

happened right after 3.4.1 update,

[Rimi]

<blockquote class='ipsBlockquote'data-author="Dmacleo" data-cid="2344304" data-time="1355445270"><p>
I am beginning to think this is hitting me too. where the feed blocks pull links and some use images would the html issue be a factor?<br />
I am wondering because whats shown in acp block design template does not match what the board actually displays.<br />
happened right after 3.4.1 update,</p></blockquote>Only if you're using ckeditor as your editor of choice in IP.Content.

Actually I'm not even aware of that's an option in IP.Content.

[Rimi]

Oh look that bug is back. I'm not even surprised anymore.

[Dmacleo]

well ckeditor is the editor for articles....which is why I wondered.

[Dmacleo]

mine was a hook issue. for some reason disabling all hooks didn't help the first time I tried it.

[Marcher Technologies]

just sighs.... Matt, are you quite seriously going to hardcode a workaround for 'Content', a first party app, and tell all modders bluntly time to use a textarea?

the parse html flag is useless if you strip all non-white-listed html... what valid reason can anyone have for stopping an admin, IN the acp, from putting in whatever html they so desire?

How am I even getting argument when it breaks working posts and other items with complex html markup on mere edit post-upgrade?

[Matt]

Marcher my dearest and nearest friend, I've already told you I'll fix this for IP.Content.

Now settle down, have a drink of something sweet and warm and relax in the knowledge that it'll all be taken care of.

[Marcher Technologies]

Marcher my dearest and nearest friend, I've already told you I'll fix this for

IP.Content.

Now settle down, have a drink of something sweet and warm and relax in the knowledge that it'll all be taken care of.

Kindly note you miss the whole point.

what am i supposed to tell users of my applications when an edit kills the html input on an acp cke configged FOR parse html?

What am I supposed to tell clients that upgrade with posts with once-valid html?

Excuse me for stating so, but a hardcoded fix for one application is plainly a copout that still does not resolve the things I am currently being hounded for by clients that this change causes.

I do not revert upgrades lightly, yet have been forced to when admins edit HTML items and all rich HTML dies, they turn and rage on me.

[Matt]

If you ask nicely, I can add a setting to bypass HTMLPurifier. A little kiss wouldn't hurt.

[Marcher Technologies]

If you ask nicely, I can add a setting to bypass HTMLPurifier. A little kiss wouldn't hurt.

:smile: that remains my confusion. How is parseHtml *not* that setting?

Reminding you this is in fact killing IPB posts.

Another flag, sounds good.... and would be a defacto-required if one uses parseHtml. :unsure:

Asking nicely that the flag that served this purpose in =>3.3 yet serves it, nay, I am now begging.

otherwise, that setting might as well be labeled stripHtml, as that is precisely what it is doing.

[Andrej]

If you ask nicely, I can add a setting to bypass HTMLPurifier. A little kiss wouldn't hurt.

Please add a setting to bypass the HTMLPurifier :)

[Dmacleo]

If you ask nicely, I can add a setting to bypass HTMLPurifier. A little kiss wouldn't hurt.

thanks.

for making me spew coffee when I read this and laughed.

[Matt]

When making a HTML forum post, I disagree that you should allow *all* HTML completely. What happens if the user pastes in a HTML frameset, or applet or object that had the potential to break the posting layout (or worse, introduce XSS)?

We have to hold the average poster's hand a little here. If you want to post complex HTML including complex frames, scripts, etc then you're probably bending what a forum post should be a little and would be better with a little mod.

Now, I do see your point with IP.Content because it allows you to use IP.Content to manufacture templates, etc so I will do the following:

add a method such as:

$editor->bypassHtmlCleaning( true );

And make sure that in the __construct block of the editor class it sets that to true if IPS_APP_COMPONENT is 'ccs'.

That way you can set it to bypass HTML cleaning in your mods and you'll be a happy bunny again.

[Marcher Technologies]

sighs.

What of the posts already present with un-white-listed html Matt? Just tell everyone don't edit or it will be stripped?

Happy for a workaround, saddened that you put me in this position, these upgrade reverts occurred because of posts being stripped on edit.

[Dmacleo]

well...If I choose to allow something on my end do I need hand holding?

theres a point of diminishing returns there. hand holding the average poster restricts others.

[Marcher Technologies]

well...If I choose to allow something on my end do I need hand holding?

theres a point of diminishing returns there. hand holding the average poster restricts others.

Here we are back at honor the configuration.

HTML allowed currently means you are allowed to post html, but anything not white-listed is stripped, ergo, you can only post CKE-HTML.

Therefore, it now means nothing.

[Dmacleo]

think of how many of the...why can't I use....insert broken html standard cmd here....questions would not crop up if allowing html actually allowed html..

I think (while my viewpoint is not a programmer viewpoint) Marcher and I agree here, let the admin make the decision what happens on their board.

cke-html.

AKA Crap Kills Embedding-html

[Marcher Technologies]

think of how many of the...why can't I use....insert broken html

standard

cmd here....questions would not crop up if allowing html actually allowed html..

Speak of the devil.

I do not understand why this is even an argument of any kind, I do not understand why I have to beg for you to honor your own settings.

:turned:

[Rimi]

Speak of the devil.

I do not understand why this is even an argument of any kind, I do not understand why I have to beg for you to honor your own settings.

:turned:

You really shouldn't word your argument like this because Matt's response is going to be to change the wording of the setting. Just look at how he's treating you in this thread. <_<

When making a HTML forum post, I disagree that you should allow *all* HTML completely. What happens if the user pastes in a HTML frameset, or applet or object that had the potential to break the posting layout (or worse, introduce XSS)?

If that happens it's the users own fault. Do you do cleaning in the SQL toolbox? I can give a user here a TRUNCATE query to put in their toolbox, but you're not holding their hand here so it will destroy their forum. HTML mode is advanced usage and advanced usage implies a sense of responsibility. It's something that we as admins use in our forums to have unique, and intuitive OPs for large threads and anything we code in there is completely intentional. If someone copies dangerous code from somewhere else then that's on them. A power user should not be punished for the faults of those who are completely inept.

add a method such as:

$editor->bypassHtmlCleaning( true );

And make sure that in the __construct block of the editor class it sets that to true if IPS_APP_COMPONENT is 'ccs'.

That way you can set it to bypass HTML cleaning in your mods and you'll be a happy bunny again.

I have not looked into it, but I'm assuming that a hook can be used to set that method to true for HTML posts where allowed. I'd be extremely surprised if I'm wrong. While I can live with that I still wish that you would step back and revise your logic. Based on what's happened in the above linked bug report, what you've said in this thread and how you've treated Marcher, and what was posted here I'm beginning to suspect that default functionality of the IPS suite is going to be extremely unforgiving to so called "power users" in favor of the main userbase who are technically inept. To be honest, whereas I have had high expectations of what's in store for IPS 4.0 I'm starting to feel quite wary. I learned all the coding I know up to this day so I could get better in my personal usage with IPB, not so I could get shunted.

P.S. If and when you do add that method, please do not forget to update the documentation.

[Marcher Technologies]

It is as simple as this.

I have clients with forums that I cannot upgrade(several we have attempted, only to pull the revert from backup), this item would completely kill countless important admin posts.

I argue on this so heavily because I do not in any way want to be in the position of recommending what I am forced to at this moment for forums that heavily use HTML posting, I want to promote upgrading to your new version, and you kneecap me here.

[Rimi]

It is as simple as this.

I have clients with forums that I cannot upgrade(several we have attempted, only to pull the revert from backup), this item would completely kill countless important admin posts.

I argue on this so heavily because I do not in any way want to be in the position of recommending what I am forced to at this moment for forums that heavily use HTML posting, I want to promote upgrading to your new version, and you kneecap me here.

And really I think if more people knew what the consequences of upgrading to 3.4 were then you'd get the same reaction as mine and Marcher's. Fact is though that most people don't understand what we're talking about here until it becomes a problem for them.

Besides, while I don't have as much insight as you do, Matt, on the usage of IPB I personally have never, ever seen someone misuse HTML posting to introduce an XSS attack of their own accord.

I understand that you don't like the way Marcher and I talk but that doesn't make us wrong.

[Matt]

This patch contains the following 3.4.2 fixes:

http://community.invisionpower.com/resources/guides.html/_/knowledge-base/341-editor-parser-updates-r262

- When IP.Content is set to allow HTML, HTML purifier is bypassed

- iFrames are no longer edited

- You can set $editor->setBypassHtmlPurify(true) in your own code to bypass HTML purification

[ZakRhyno]

Should you not apply this patch as it is a security issue?