Asking again...
If someone were to get gung-ho about implementing access control measures in MediaWiki that go way beyond the immediate needs of Wikipedia, would you prefer that that person/group:
A. Submit patches for inclusion in mainline MediaWiki B. Submit patches to extend the MediaWiki core to allow for a security layer C. Submit patches to modularize/wrap some MediaWiki components (e.g. the parser) in a way that they can be used as libraries for an otherwise forked/rewritten wiki product D. Fork MediaWiki
Curious Robla
On Thu, 2005-11-17 at 18:20 -0800, Rob Lanphier wrote:
On Tue, 2005-11-15 at 18:53 -0800, Brion Vibber wrote:
In general, I strongly recommend against trying to hack in 'access restrictions' to MediaWiki. If you *need* them, you will likely end up with a very insecure system which will FAIL you. If you *don't* need them, then why bother?
If you *need* access restrictions, I recommend that you use some software which supports this explicitly. Don't just use MediaWiki because it sounds neat or it's the first wiki you saw; you should only use it if it's actually appropriate for your needs.
I'd like to ask a clarifying question regarding this stance.
Let's say that someone got really gung-ho about implementing granular access control in MediaWiki. They choose MediaWiki because they really need markup compatibility and a lot of the other features.
There's a whole continuum of things that this someone/someones could do to accomplish and maintain this:
A. Submit patches for inclusion in mainline MediaWiki B. Submit patches to extend the MediaWiki core to allow for a security layer C. Submit patches to modularize/wrap some MediaWiki components (e.g. the parser) in a way that they can be used as libraries for an otherwise forked/rewritten wiki product D. Fork MediaWiki
I'm asking this only as a theoretical question for now. I've seen it come up on the list enough times, and I know that in my last job, I would have been keenly interested in this.
My hope would be that "B" would be the correct answer. In particular, if the hooks existed to extend/replace the core classes, I think one could plug a lot of holes in the security layer. The temptation would be to literally extend those classes (e.g. "class SecureArticle extends Article"), but I think that the security layer would actually need to reimplement the interface, so that when new calls are introduced, the secure implementation fails rather than "succeed" to deliver a page to an unauthorized source.
Rob
p.s. I coulda swore I asked this and even got an answer before, but didn't find it in my inbox. Sorry if this is a duplicate from a few months ago.
MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l