Combining the best of using a wiki for ease of adoption and
participation with revision management using Git is possible.
One engine that does this is ikiwiki. It renders html pages from markup
that is stored in an underlying git or svn repository, much like Bloxsom
(for those who are familiar with it) did years ago.
The benefits are that:
1) ikiwiki allows editing through the wiki interface as one would expect
2) a git post-commit hook can easily be setup to force the underlying
repository to pull from a remote with more strict access controls. The
same code that Justin and I are working on for the post-commit URL with
Jira can be repurposed to update the underlying repository in the event
that someone adds malicious code etc.
Anastasia, Colin, if this sounds at all appealing or like a reasonable
combination of requirements, would setting up a test instance make sense?
Regards, Jamon
On 2/9/2011 10:16 PM, Colin Clark wrote:
Hi Anastasia,
I think there are a few interesting questions we should consider beyond just, "how
much of a concern should this be?" Obviously security is always an important
concern. Let's see if we can unpack the potential risk and determine what tools we have
available to us for mitigating it.
There's certainly a risk that, if sample code is embedded directly in another
page, someone might post a script that could scrape data from the wiki or phish
for user input and then send it back to another server via JSONP. That's the
nature of mashups. There are a number of ways we could handle this, ranging
from only displaying code snippets within an iFrame to reviewing all code
examples and posting them as read-only.
That said, we've already got some pretty good tools for monitoring changes to
our wiki. As a community, there are many of us who keep an eye on every change
to our documentation.This lowers the risk quite a bit. To put it another way,
we are constantly reviewing all changes to our wiki in real time. As a result,
we can probably afford to be welcoming.
I think there are some nice low tech, social solutions to issues like this. A
combination of isolating sample code in iFrames and ensuring that our community
stays vigilant seems like a reasonable balance between openness and caution.
Colin
On 2011-02-08, at 3:56 PM, Cheetham, Anastasia wrote:
Our goals for the new documentation include (among others):
1) community editing, and
2) live demos within pages
This seems to open up a security concern: Support for community editing could
allow editors to add malicious code to our documentation pages (not that anyone
in our community would do that, but...).
Some of the proposed systems involve a review process that would prevent this
(source files in git requiring a pull, for example), but some wikis
(Confluence, for example) allow editors to embed HTML and JS right in the page.
How much of a concern should this be? Should a vetting provision for code be a
requirement of any system we adopt? Any other thoughts on this issue?
---
Colin Clark
Technical Lead, Fluid Project
http://fluidproject.org
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work
