]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/plugins/comments/discussion.mdwn
Exclude working directory from library path (CVE-2016-1238)
[git.ikiwiki.info.git] / doc / plugins / comments / discussion.mdwn
index 2a87a3d935e2bacb521bedd2984333e808df0944..0641ddcc9aedecc403a377d6853663425aec2411 100644 (file)
@@ -1,3 +1,18 @@
+## Syndication autodiscovery for comment feeds
+
+A standard `\[[!inline]]` directive adds links to the autogenerated syndication feeds using link tags in the header:
+
+    <link rel="alternate" type="application/rss+xml" title="$title" href="$page.atom" />
+    <link rel="alternate" type="application/atom+xml" title="$title" href="$page.atom" />
+
+These links aren't added to my pages that include comments even though comments generate syndication feeds.  How can I configure the comments plugin to add these links to the header?  (These links are required for user-agent autodiscovery of syndication feeds.) --[[anderbubble]]
+
+## Moderating comments from the CLI
+
+How do you do this, without using the UI in the Preferences?
+
+Please put this info on the page. Many thanks --[[Kai Hendry]]
+
 ## Why internal pages? (unresolved)
 
 Comments are saved as internal pages, so they can never be edited through the CGI,
 ## Why internal pages? (unresolved)
 
 Comments are saved as internal pages, so they can never be edited through the CGI,
@@ -60,7 +75,7 @@ spam problems. So, use `check_canedit` as at least a first-level check?
 > have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
 > should take a pagespec, so you can have postcomment(link(tags/commentable))?)
 >
 > have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
 > should take a pagespec, so you can have postcomment(link(tags/commentable))?)
 >
-> This is why `anonok_pages => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
+> This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
 > are necessary to allow anonymous and logged-in editing (respectively).
 >
 >> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
 > are necessary to allow anonymous and logged-in editing (respectively).
 >
 >> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
@@ -161,3 +176,82 @@ Raw HTML was not initially allowed by default (this was configurable).
 >>> 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]]
 >>> 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]]
+
+----
+
+I have a test ikiwiki setup somewhere to investigate adopting the comments
+plugin. It is setup with no auth enabled and I got hammered with a spam attack
+over the last weekend (predictably).  What surprised me was the scale of the
+attack: ikiwiki eventually triggered OOM and brought the box down. When I got
+it back up, I checked out a copy of the underlying git repository, and it
+measured 280M in size after being packed. Of that, about 300K was data prior
+to the spam attack, so the rest was entirely spam text, compressed via git's
+efficient delta compression.
+
+I had two thoughts about possible improvements to the comments plugin in the
+wake of this:
+
+ * comment pagination - there is a hard-to-define upper limit on the number
+   of comments that can be appended to a wiki page whilst the page remains
+   legible.  It would be useful if comments could be paginated into sub-pages.
+
+ * crude flood control - asides from spam attacks (and I am aware of
+   [[plugins/blogspam]]), people can crap flood or just aggressively flame
+   repeatedly. An interesting prevention measure might be to not let an IP
+   post more than 3 sequential comments to a page, or to the site, without
+   at least one other comment being interleaved. I say 3 rather than 2 since
+   correction follow-ups are common.
+
+-- [[Jon]]
+
+
+---
+
+## Comment threads
+
+Any thoughts about implementing some simple threading in the comments?
+
+Or at least a reply functionality that quotes the subject/contents?
+
+-- [[iustin]]
+
+---
+
+## Disabling certain formats for comments
+
+It seems that comments plugin allows using all enabled formats and
+there is not way to disable some of them. For my blog, I want to use
+additional formats for writing posts but I do not want commenters to
+use those formats because it would be a security problem.
+
+Any suggestions or hints how to implement this?
+
+-- [[wentasah]]
+
+> I've implemented this. See [[todo/Restrict_formats_allowed_for_comments]].
+> --[[wentasah]]
+
+## URLs in anonymous-style comments committed directly via VCS
+
+[[!template id=gitbranch branch=schmonz/comments-anonymous-url-vcs author="[[schmonz]]"]]
+
+I recently imported my site from Textpattern into ikiwiki (using
+an `ikiwiki-import` program that may someday make its way into
+ikiwiki proper). Textpattern's comments behave much like ikiwiki's
+anonymous comments, so piping each imported comment through
+`ikiwiki-comment` and regenerating the site with `comments_allowauthor=1`
+preserved almost all the information.
+
+What's missing: if a comment directive has a `url` param, I'd expect
+the rendered page to href the author's name to that URL. This works
+as I expect for new comments added via the CGI, but not for imported
+comments added via the VCS directly.
+
+My branch has a fix that doesn't break `t/comments.t`, doesn't
+appear to break anonymous or signed-in comments via the CGI in any
+way I've tried, and lets me render my (incredibly valuable ;-)
+imported blog comments with full fidelity. OK to commit?
+
+> Ship it. --[[smcv]]
+
+>> Thanks, have done. --[[schmonz]]