#6642 closed defect (bug) (fixed)
Commenters can break page validation via HTML comments
| Reported by: | schiller | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.6.1 |
| Component: | General | Version: | 2.6 |
| Severity: | normal | Keywords: | has-patch 2nd-opinion |
| Cc: | Focuses: |
Description
As per http://www.w3.org/TR/REC-xml/#sec-comments, XML does not like two dashes (--) in comments, nor does it like comments ending in --->. This should be fixed in kses
Attachments (1)
Change History (17)
#3
@
18 years ago
Can you clarify this? When is wptexturize() called? Is this something that has changed since WP 2.3.3?
#4
@
18 years ago
- Milestone 2.7
- Resolution → worksforme
- Status new → closed
No, wptexturize() has been around since at least version 1.5. All comments and posts are run through it by default before being displayed.
Log out and make a comment like this on your blog:
This is a -- test comment over here --->
It will display at this valid XHTML:
This is a — test comment over here —>
Closing as worksforme.
#5
@
18 years ago
Oh, and to answer your "When is wptexturize() called?" question, look at /wp-includes/default-filters.php. You'll find this line in it:
add_filter('comment_text', 'wptexturize');
#6
@
18 years ago
Actually I had already confirmed this was indeed a problem - someone was logged out and made the following comment on my WP 2.3.3 blog:
Comment: <!-- foo -- bar -->
And it resulted in a Yellow Page of Death when rendered as XHTML. That's why I dug through and came up with this 2-line patch for kses.
Note that the comment stays hidden i.e. it actually stays a HTML comment it doesn't get escaped to be
Comment: <!-- foo -- bar -->
I do not have the "WordPress should correct invalidly nested XHTML automatically" checkbox checked (Options > Writing). Can you describe the settings on your blog that relate to translating markup?
#7
@
18 years ago
- Keywords needs-patch added; xhtml kses removed
- Milestone → 2.7
- Resolution worksforme
- Status closed → reopened
- Version → 2.5
Okay, well that's an entirely different issue. ;)
Confirmed that no-access users can post HTML comments, something that they shouldn't be able to do IMO. It's specifically allowed in the code though, so then I guess we should just make sure it doesn't break validation.
#8
@
18 years ago
- Summary kses should not allow multiple hyphens in comments → Commenters can break page validation via HTML comments
#9
follow-up:
↓ 10
@
18 years ago
Ok, thanks - I should have clarified between the two different types of comments ;)
I did attach a patch for this bug - does it need to get reviewed or something? (Just curious about your addition of the 'needs-patch' keyword)
#10
in reply to: ↑ 9
@
18 years ago
- Keywords has-patch 2nd-opinion added; needs-patch removed
Replying to schiller:
I did attach a patch for this bug - does it need to get reviewed or something? (Just curious about your addition of the 'needs-patch' keyword)
Sorry, force of habit and I thought your patch merely removed all double dashes. It was in the wee hours of the morning and I didn't realize your patch was specifically targeted at HTML comments. My apologies.
Switched to the "has-patch" tag. :)
#12
@
18 years ago
- Milestone 2.7 → 2.6.1
- Resolution fixed
- Status closed → reopened
Re-open for 2.6.1
#14
@
17 years ago
- Resolution fixed
- Status closed → reopened
- Version 2.5 → 2.9.1
This appears broken again in WP 2.9.1 (though I did verify my fix appears in kses.php still). No idea why it's happening.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
Patch for kses, prevents adjacent hyphens in a HTML/XML comment