60 lines
3.0 KiB
Markdown
60 lines
3.0 KiB
Markdown
## 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]]
|