MHart wrote:

I added an extension <restrict>Group or Users</restrict> and the page redirects if the user isn't in that group or user list.

This sounds like it will fail in numerous circumstances where text is shown without full parsing: * action=edit * action=raw * Special:Export * diff * text in Special:Newpages RSS feed * diff in Special:Recentchanges RSS feed * Search text extracts

and probably more.

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.

-- brion vibber (brion @ pobox.com)

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

On 11/22/05, Jej jejc@free.fr wrote:

It seems that many people need this feature. Since I published this patch (http://conseil-recherche-innovation.net/index.php/1974/04/11/41-restrict-pag...), we have 25% of visits on this single article. Generaly people need restriction feature to manage small wikis, private intranets. I guess they choose mediawiki for the syntax, templates, and reliabilty/community support, and not for the ability to manage projects as big as wikipedia nor encyclopedies.

From a wikipedia point of view, I think nobody wants more restriction features (protect is enough). We cannot polute the core of MW with features not useful for WP, it's difficult to maintain patches for ages, and it's not necessary to carry WP specific features in a forked project. So my choice would be a fifth... E. To write some specifications from needs, abstract the problem, and start a new project :) Any ideas ?!...

I think it would be nice to have everything contributed into the core wikipedia project itself, with a simple switch to disable things, so that the wikimedia projects aren't, for once, themselves forced to have a community feature.. as opposed to them forcing features on the community. ;)

Or rather, the traditional "protect" feature would eventually just mean "protect against writes from those not in the administrators group"..

There *could* be core security and code tidyness benefits from rewriting portions of the way mediawiki handles things.

If a new project was branched off.. it would have to keep up with all the code changes from the mother project, which won't work for very long. Take a look at fluxbox, for example.. blackbox shifted and they're now far behind -- unable to import the styles and such from blackbox, which they still claim to be able to do. That's why I'd be strongly against the notion. .. unless MediaWiki was reimplemented in Ruby/postgres.. *hides* ;)

Rob Lanphier wrote:

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

The main thing is that we (at least I ;) don't want to have to maintain code that's totally useless to us, and a security layer adds maintenance obligations to that useless-to-us code (if there's a hole, we have to patch it and issue new releases, and if it exists people are more likely to want to rely on it, increasing the weight of the obligation). Thus my knee-jerk reaction is D; if somebody wants to maintain such a beast, let them.

B. is possibly appropriate though; I hacked in the AuthPlugin so people could work on things like the LDAP and other custom authentication interop things separately from the main code, without adding too much to the core code complexity (and others have helped improve it, and it could probably still use improvement ;)

It _might_ make sense to have a similar access control interface which can then be plugged in, though I'm not sure how much plugging would really need to be done if the infrastructure for all the plug points would actually be there.

Jej wrote:

So my choice would be a fifth... E. To write some specifications from needs, abstract the problem, and start a new project :) Any ideas ?!...

Specs and abstractions are always nice to have before one starts. ;)

-- brion vibber (brion @ pobox.com)