1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
## Problem: `inline` <a id="inline"></a>
Web slides are sort of a regular web page, but not exactly: no action
links, and almost none of the other accoutrements of `page.tmpl`. The
branch's current behavior is that Remark slides are naively inlined like
any other page, which -- because the Markdown is deliberately not being
rendered by ikiwiki -- results in the slide source being displayed (and
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"? --[[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? --[[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]]
|