doc/plugins/contrib/remark/discussion.mdwn

   1 ## Problem: `inline` <a id="inline"></a>
   2
   3 Web slides are sort of a regular web page, but not exactly: no action
   4 links, and almost none of the other accoutrements of `page.tmpl`. The
   5 branch's current behavior is that Remark slides are naively inlined like
   6 any other page, which -- because the Markdown is deliberately not being
   7 rendered by ikiwiki -- results in the slide source being displayed (and
   8 not elegantly). Clicking through to the slides works right, of course.
   9
  10 Should [[inline]] (and more generally [[ikiwiki/PageSpec]]) understand
  11 that web slides are not exactly regular pages? And/or should this plugin
  12 detect when slides are being inlined and allow ikiwiki to process the
  13 Markdown as a sort of "preview"? --[[schmonz]]
  14
  15 > If you want web slides to not be a normal page, that's what internal
  16 > pages are for. An internal page has an extension (file type) starting
  17 > with `_`, and has the following properties:
  18 >
  19 > * `foo._ext` does not automatically render `foo[/index].html`
  20 > * `glob(foo)` (for which unadorned globs are syntactic sugar) does not
  21 >   match it, you have to use `internal(foo)`
  22 > * [[plugins/editpage]] won't edit it
  23 >
  24 > I'd be very tempted to use `foo._remark` and set it up so all such pages
  25 > are copied to `foo.html` unchanged. You'd probably have to add a new hook
  26 > that is run instead of most or all of `render()`, and also make those
  27 > pages exempt from `derender_internal()`?
  28 >
  29 > When a remark page is inlined (via `internal()` if it's internal)
  30 > I think it might be nice to pass it through (the htmlize function of)
  31 > ikiwiki's normal [[plugins/mdwn]] instead. --[[smcv]]
  32
  33 ## Concern: safety of web-editing <a id="editing"></a>
  34
  35 Even though `remarkpage.tmpl` has no action links, is it still possible
  36 for someone to trick their way into web-editing a slide deck? And if
  37 they do, is that dangerous? --[[schmonz]]
  38
  39 > Yes, it's likely both possible and dangerous. If you've already
  40 > deployed this plugin, make sure it's covered by [[plugins/lockedit]].
  41 >
  42 > Every *page* that is not *internal* can be edited. Look at
  43 > [[plugins/editpage]] for the (only) logic that is applied when deciding
  44 > whether to accept an edit: whether there is an action link is irrelevant.
  45 >
  46 > Here *page* is a jargon term for something matching `page()`, i.e. its
  47 > extension is the same as the name of a `htmlize` hook, while *internal*
  48 > means a *page* whose extension additionally starts with `_`.
  49 >
  50 > I think there's a cross-site scripting vulnerability here. If there is
  51 > some Markdown source that is seen as OK by
  52 > [[plugins/htmlscrubber]] and [[plugins/htmlbalance]], but induces
  53 > remark.js to produce HTML that is then evaluated in the security context
  54 > of your wiki and executes attacker-supplied JavaScript in visitors' browsers,
  55 > then an attacker able to edit the remark source could act with the
  56 > privileges of your wiki and anything else that shares its origin
  57 > (domain name). In particular, the attacker could steal login cookies.
  58 > The simplest proof-of-concept would be something like
  59 > `[click here](javascript:alert("XSS! " + document.cookie))`. --[[smcv]]