|
in reply to RFC: self hosting Perl 6 string wiki
It sounds like a cool idea, but I have my doubts:
- Security: contributing code in a wiki and executing it on the server sounds like a very bad idea in terms of security
- Usefulness: why the heck do you need to run arbitrary code on a wiki page?
- Maintainability: There's a reason why code and templates are usually separated, and that is maintenance.
That said, I'm sure it's a very nice proof-of-concept demonstration of what parrot is able to run, or hopefully will be able. And adding wikicreole markup to November is certainly a very good idea. |
Re^2: RFC: self hosting Perl 6 string wiki
by amarquis (Curate) on Sep 05, 2008 at 14:57 UTC
|
Agreed, the security implications give me fits, but rolling new functionality into November sounds great.
Applied things like November are the things that get me out of my "ignoring Perl 6" shell and actually looking into it.
| [reply] |
Re^2: RFC: self hosting Perl 6 string wiki
by raiph (Deacon) on Sep 08, 2008 at 22:09 UTC
|
Hey Moritz,
Thanks for the feedback. Any more greatly appreciated.
> Security:
- Parrodocs will run in a VM (eg openVZ). It will be possible to quickly restore a Parrodocs to a known "good" point. Data that must be any or all of persistent, secret, or ACIDly written, lives on a different server (eg an Amazon one).
- Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.
(Due to the many misunderstandings I've read online over the years, I hesitate to mention Safe.pm -- "a failed experiment" -- and I wish to emphasize that use of such a module is not part of my plans at this point. That said, I still expect a useful Parrot version of Safe to be written within the next couple years and I would expect it to be useful in Parrodocs.)
> Usefulness: why the heck do you need to run arbitrary code on a wiki page?
Well, as another approximation, Parrodocs isn't really a wiki, it's sort of like a PHP (done right). (But please remember, this is again an approximation; please don't respond with "I hate PHP", because Parrodocs is really a squeakish Perl6/website IDE. Well, actually it's a platform for experimenting with non-linear communication. Well ... urgh. Part of the point of this meditation was to work out which part of the elephant to describe first next time I try.)
> Maintainability: There's a reason why code and templates are usually separated, and that is maintenance.
Newbies don't care about maintenance, and they'll be delighted that they can just write "Hello $mom" and it'll DWIM. In contrast, an advanced developer might want total separation -- perhaps an XML + XSLT solution. I think Parrodocs will cover both extremes and variants in between.
I look forward to any further thoughts from my fellow Monks... | [reply] |
|
|
| [reply] |
|
|
Hey Moritz,
Thankyou again. I hope you are enjoying this dialog -- I sure appreciate it. :)
That doesn't account for attacks that can be used to steal passwords from other users (think of CSRF, faked login screens etc.), which kinda defeats your next point:
Any functionality considered vulnerable to corruption (which means almost anything other than browsing the site), requires an account and login.
Let me back up a mo...
As far as system integrity and availability is concerned, I was thinking the approach I listed under point 1 in my previous reply (VM etc.) would be sufficient, on its own, for many useful projects.
This is a central issue. Do you think that the following can, at least in theory, work?
No logins; all data in the Parrodocs (and its underlying server) (potentially) public; all data (and code) in the Parrodocs (and its underlying server) open to temporary corruption or worse.
Stealers will eventually pass Parrodocs by because there's nothing worth stealing; no private data, and no worthwhile computation because mallory is more likely to be spotted on (and booted off of) a Parrodocs server than on a more conventional owned server.
(Vandals, otoh, might have a lot of fun.)
When trouble is spotted, a sysop or a bot either fixes the relevant page(s) or restarts the server and rolls all pages forward to the last known good set.
A login provides some value. It isn't about establishing trust and it won't even stop deliberate trouble makers, just as wikipedia's login feature doesn't, but it'll make a useful difference, I think.
if it's more like PHP than a wiki, where is the connection to
? :)
| [reply] |
|
|
|
|
|
|
