Problem: inline

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 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)
• 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 mdwn instead. --smcv

Concern: safety of web-editing

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 lockedit.

Every page that is not internal can be edited. Look at 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 htmlscrubber and 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