Other than search, what fragmentation issues are you concerned about
from separate wikis? I'm wondering if it would be easier to add
interwiki searching than to shut off all the unanticipated holes in
an intrawiki access control system. An extension to pass an HTTP
search request to another wiki and reformulate the links would
probably not be too hard to write. With either separate wikis or
controlled access, the permutations of how users might screw up are
mind boggling, especially if the groups are not just nonintersecting
subsets of larger groups. But I think it might be easier to
configure interwiki searching so that searches only are allowed to
the appropriate wiki instances.
Anyway, just my $0.02. I hope I'm wrong and you come up with
something great! Some random questions/comments about your approach:
I'd be interested in how you set up the extension to evaluate
properly from inside a template/transclusion. I think there are some
extensions (Cite.php?) that have had problems with that.
When a privileged user creates a new page link from a secured page,
do you imagine that the new page will be secure by default? Or will
someone patrol the wiki and administer adding security definitions.
Do you want to block unauthorized users from even knowing that pages
exist? By analogy to shell, ls doesn't show files to a user who
doesn't have permissions on a directory. If you don't, then I think
you're going to discourage users from using the wiki by giving them
lots of "access restricted" messages when they click on something
that looks like a link. If you do want to hide pages you're going
to need group-specific handling of search, categories, allpages, what
links here, etc. Search returns a snippet of the page. Is that a
problem?
It also looks like you are thinking of not using namespaces as the
level for access restriction. One of the advantages of restricting
at the namespace level is that there is already control over
searching to include or exclude specific namespaces. It might be not
so hard to exploit that. The disadvantage is that your users will
put things in the wrong namespaces by mistake.
=====================================
Jim Hu
On Dec 7, 2006, at 9:32 AM, Fernando Correia wrote:
I have reviewed the protection extensions available.
None really does
what my company needs, so I'm venturing into creating a new one, based
on ideas from the existing ones.
If it works this is how it will be used:
// 1. Use the MediaWiki features to create associate users to user
groups.
//
// 2. Create named security definitions using a markup like this in a
protected page:
// <security-definition name="Official documentation">
// <deny action="read">guests</deny>
// <allow action="read">all</allow>
// <allow action="edit">sysops, writers</allow>
// </security-definition>
//
// 3. Create a template to ease the page security specification:
// Template:Official_documentation
// This is an official documentation page. The access is restricted.
// <security>Official documentation</security>
//
// 4. Use the security definition template in the pages that should be
protected by it:
// {{Official documentation}}
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l