X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/30ce222a2e069bc2d383a09b6ee3ffc57e5f33eb..6ab4dee7287ee13d21435402234eef3c93f1841e:/doc/plugins/contrib/remark/discussion.mdwn

diff --git a/doc/plugins/contrib/remark/discussion.mdwn b/doc/plugins/contrib/remark/discussion.mdwn
index 1c9cdebb3..ab8d40912 100644
--- a/doc/plugins/contrib/remark/discussion.mdwn
+++ b/doc/plugins/contrib/remark/discussion.mdwn
@@ -10,10 +10,50 @@ not elegantly). Clicking through to the slides works right, of course.
 Should [[inline]] (and more generally [[ikiwiki/PageSpec]]) understand
 that web slides are not exactly regular pages? And/or should this plugin
 detect when slides are being inlined and allow ikiwiki to process the
-Markdown as a sort of "preview"?
+Markdown as a sort of "preview"? --[[schmonz]]
+
+> If you want web slides to not be a normal page, that's what internal
+> pages are for. An internal page has an extension (file type) starting
+> with `_`, and has the following properties:
+>
+> * `foo._ext` does not automatically render `foo[/index].html`
+> * `glob(foo)` (for which unadorned globs are syntactic sugar) does not
+>   match it, you have to use `internal(foo)`
+> * [[plugins/editpage]] won't edit it
+>
+> I'd be very tempted to use `foo._remark` and set it up so all such pages
+> are copied to `foo.html` unchanged. You'd probably have to add a new hook
+> that is run instead of most or all of `render()`, and also make those
+> pages exempt from `derender_internal()`?
+>
+> When a remark page is inlined (via `internal()` if it's internal)
+> I think it might be nice to pass it through (the htmlize function of)
+> ikiwiki's normal [[plugins/mdwn]] instead. --[[smcv]]
 
 ## Concern: safety of web-editing <a id="editing"></a>
 
 Even though `remarkpage.tmpl` has no action links, is it still possible
 for someone to trick their way into web-editing a slide deck? And if
-they do, is that dangerous?
+they do, is that dangerous? --[[schmonz]]
+
+> Yes, it's likely both possible and dangerous. If you've already
+> deployed this plugin, make sure it's covered by [[plugins/lockedit]].
+>
+> Every *page* that is not *internal* can be edited. Look at
+> [[plugins/editpage]] for the (only) logic that is applied when deciding
+> whether to accept an edit: whether there is an action link is irrelevant.
+>
+> Here *page* is a jargon term for something matching `page()`, i.e. its
+> extension is the same as the name of a `htmlize` hook, while *internal*
+> means a *page* whose extension additionally starts with `_`.
+>
+> I think there's a cross-site scripting vulnerability here. If there is
+> some Markdown source that is seen as OK by
+> [[plugins/htmlscrubber]] and [[plugins/htmlbalance]], but induces
+> remark.js to produce HTML that is then evaluated in the security context
+> of your wiki and executes attacker-supplied JavaScript in visitors' browsers,
+> then an attacker able to edit the remark source could act with the
+> privileges of your wiki and anything else that shares its origin
+> (domain name). In particular, the attacker could steal login cookies.
+> The simplest proof-of-concept would be something like
+> `[click here](javascript:alert("XSS! " + document.cookie))`. --[[smcv]]