diff options
| -rw-r--r-- | doc/plugins/contrib/comments/discussion.mdwn | 37 |
1 files changed, 34 insertions, 3 deletions
diff --git a/doc/plugins/contrib/comments/discussion.mdwn b/doc/plugins/contrib/comments/discussion.mdwn index 8f98c1cb5..a054dd55d 100644 --- a/doc/plugins/contrib/comments/discussion.mdwn +++ b/doc/plugins/contrib/comments/discussion.mdwn @@ -1,4 +1,4 @@ -# Why internal pages? (unresolved) +## Why internal pages? (unresolved) Comments are saved as internal pages, so they can never be edited through the CGI, only by direct committers. Currently, comments are always in [[ikiwiki/markdown]]. @@ -56,7 +56,7 @@ only by direct committers. Currently, comments are always in [[ikiwiki/markdown] >>> for this plugin, and the last is harmless; you seem to think the first >>> is useful, and the other two are harmful. --[[smcv]] -# Access control (unresolved?) +## Access control (unresolved?) By the way, I think that who can post comments should be controllable by the existing plugins opendiscussion, anonok, signinedit, and lockedit. Allowing @@ -92,7 +92,7 @@ spam problems. So, use `check_canedit` as at least a first-level check? > reliant on the fact that internal pages can't be edited. Perhaps there should be a > `editable_pages` pagespec, defaulting to `'*'`? --[[smcv]] -# comments directive vs global setting (resolved?) +## comments directive vs global setting (resolved?) When comments have been enabled generally, you still need to mark which pages can have comments, by including the `\[[!comments]]` directive in them. By default, @@ -137,3 +137,34 @@ the comments. [This requirement has now been removed --[[smcv]]] >>>> conffiles.) --[[smcv]] >>>>> I've switched my branch to use page.tmpl instead; see what you think? --[[smcv]] + +## Raw HTML (resolved?) + +Raw HTML was not initially allowed by default (this was configurable). + +> I'm not sure that raw html should be a problem, as long as the +> htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering +> out directives, as a special case. --[[Joey]] + +>> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy +>> or htmlbalance turned on, then there should be no way the user can forge a comment; +>> I was initially wary of allowing meta directives, but I think those are OK, as long +>> as the comment template puts the \[[!meta author]] at the *end*. Disallowing +>> directives is more a way to avoid commenters causing expensive processing than +>> anything else, at this point. +>> +>> I've rebased the plugin on master, made it sanitize individual posts' content +>> and removed the option to disallow raw HTML. Sanitizing individual posts before +>> they've been htmlized required me to preserve whitespace in the htmlbalance +>> plugin, so I did that. Alternatively, we could htmlize immediately and always +>> save out raw HTML? --[[smcv]] + +>>> There might be some use cases for other directives, such as img, in +>>> comments. +>>> +>>> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not +>>> allow users to do annoying things) or if it will continue to be in the +>>> future. Hard to predict really, all that can be said with certainty is +>>> all directives will contine to be inexpensive and safe enough that it's +>>> sensible to allow users to (ab)use them on open wikis. +>>> --[[Joey]] |