Move some more discussion here

diff --git a/doc/plugins/contrib/comments/discussion.mdwn b/doc/plugins/contrib/comments/discussion.mdwn
index 8f98c1cb5cd107fb149a89764b7ab049845dbeed..a054dd55db635eb6530df02c8bc131b7b57ae249 100644 (file)
--- 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]]