Matt Raible wrote:
> I've been skimming this thread, but not thoroughly reading each
message.
> One
> of the things I'd like to see (that doesn't happen now) is to allow
full
> HTML - no ifs ands or buts. Meaning that I can add JavaScript or any
HTML
> tags I'd like to a comment. In addition, it would be nice to add some
> comment-post pre-processors that allow replacing \n with <br/> before
the
> entry gets put in the database.
> The first feature is for me. I seem to comment as much on my blog as
others
> do. It's frustrating for me when my HTML gets escaped. Furthermore,
since I
> get almost instant notification of comments - I know when to delete
those
> that have XSS text.
yep, those are both things that we are trying to solve for with this
work. i've already introduced the concept of comment plugins into the
trunk and those basically work like our entry plugins, they get applied
to comments as they are rendered and allow you to transform the text any
way you want. we have 2 plugins migrated from old functionality, one
which does the autoformatting as you described (text paragraphing to
html paragraphing) and one which restricts the content to only a subset
of html.
i'm not sure we'll have a way to configure things so that certain users
have different restrictions on what they can post in comments though.
>
> The 2nd feature is for readers. A lot of people comment on my blog w/o
> doing
> "preview" first and end up with comments that run together - even
though
> there's line breaks in their entry. I realize I can change the macro to
> render the output different, but that affects all comments - whereas I
just
> want to affect new ones. I regularly go into my database and format
> comments
> by adding <br/><br/> tags, but it'd be nice not to have to do that.
yep, that's in the autoformatting plugin now. so if you want to do the
safe thing you will be able to disable html in comments and then apply
the autoformat plugin and it will format things appropriately.
-- Allen
>
> Matt
>
> On 7/12/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Dave wrote:
>> > On 7/11/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> >> I personally like the idea of rejecting comments with html in them
>> when
>> >> the admin has disabled html in comments because it seems like the
>> safest
>> >> and most consistent thing to do. My feeling is that it's more
>> likely
>> >> that users will enter in a comment and try to use html than it is
that
>> >> users will be using the < and > characters in a non-html
fashion. So
>> >> rejecting the comment and telling them not to use those characters
>> will
>> >> be appropriate and fitting most of the time.
>> >>
>> >> There certainly will be some cases where users aren't trying to put
in
>> >> html and their comment gets rejected, but my feeling is that those
>> cases
>> >> will be relatively few and with a decent error message they should
be
>> >> able to fix it without much of a problem.
>> >
>> > I don't like the idea of rejecting a comment because it has a
bracket
>> > that definitely doesn't seem right. If HTML Is disabled then we
should
>> > treat the comment as plain text. An angle bracket is allowed in
plain
>> > text and is not considered HTML.
>>
>>
>> I don't like it either, but I'm not sure that will happen all that
>> often. What we really need is a better parser so that we could
actually
>> distinguish between real html and casual use of the < and >
characters.
>>
>>
>> >
>> > I think the most consistent thing to do is this:
>> >
>> > If HTML is disabled in comments that means that Roller consider the
>> > comment content to be of type text/plain. Add a content-type
field to
>> > the comment table so we can save that. And whenever Roller displays
>> > content of type text/plain in HTML or XML it must be escaped.
>> >
>> > If HTML is enabled then consider the content type to be text/html.
>> > When we display HTML in a comment we always do the HTML
>> > subsetting/white-listing bit. I don't think we should ever display
raw
>> > comment HTML.
>>
>>
>> Okay, that sounds like a pretty good plan to me. However, I'm not
sure
>> I agree about forcing the HTML subsetting/white-listing part. While I
>> agree that it is typically dangerous and undesirable, we have to
>> remember that many times blog applications are used in trusted
>> environments now, such as corporate intranets, and in those cases it
>> would be entirely valid to just allow any html in comments.
>>
>> I guess I also think that it seems silly to not make that an option,
>> since undoubtably someone will want to do things that way.
>>
>> So I will add one more column to the roller_comment table for
>> content-type and tweak the upgrade process so that it gets properly
set
>> based on the previous value of the 'users.comments.escapehtml'
property.
>> If that property was enabled then the content-type will be
text/plain
>> and if not then it will be text/html.
>>
>>
>> >
>> > Going farther down that road, maybe we shouldn't have a "Allow HTML
in
>> > comments" property. Instead, have a "Set content-type to be used for
>> > new comments" and offer options Text, HTML and XHTML.
>> >
>> > This will also make it clear how comments should be treated when
in a
>> > feed. See the Atom <content> elements type attribute here:
>> > http://tools.ietf.org/html/rfc4287#page-14
>>
>>
>> I think that's fine, but it's extra effort to do that and I don't have
>> time for it right now. I think just sticking with a simple html or
>> plain text option will be fine for now, and there won't be any issues
>> with expanding on that down the road and allowing admins to choose
their
>> own content-type if they want.
>>
>> So for right now I'm just going to leave things as is and provide just
a
>> single "Allow HTML in comments?" checkbox, which is effectively the
same
>> functionality we have right now. If HTML is allowed then the
>> content-type for incoming comments will be set to text/html, otherwise
>> it will be set to text/plain.
>>
>> Cool?
>>
>> -- Allen
>>
>>
>> >
>> >
>> > If we don't want to go down that road and add a content-type, I
think
>> > we should stick with the practice of escaping comments that are not
>> > supposed to be HTML rather than rejecting any angle brackets or HTML
>> > tags. I don't think you have enough justification for making such a
>> > behavior change.
>> >
>> > - Dave
>> >
>> >
>> >
>> >
>> >
>> > - Dave
>>
>
>
>
