Hi,
OK, I know one of key feature of a Wiki is "unrestricted access to everyone", but there are some times when you definitely want to have a subpart of a Wiki to be more "private", or "read only", using a more sophisticated scheme than white-lists (no, I don't want to create a separate wiki).
So, I'm willing to give it a stab and see if I can turn that out into an extension, as a small spare-time project (that would probably be completed in 2012 I guess). In the meantime would you guys be open to add some hooks into 1.4 / 1.5 ? Or pointing out where to put them ?
For example, I have the feeling Title::userCanEdit() and Title::userCanRead() would be two interesting places to put event/hooks.
I'm not exactly sure what userCanRead() prevent from though, any clue ? For example, if I check the "Special::Recent Changes", it seems to me that if user can not read a given page P, he should certainly not be able to see the comments that were entered when someone else modified that page P (neither should he be able to see the "diffs"). My fear is that I miss one of the many ways to see the contents of a page.
Actually I just checked 1.4 and it seems there is a new Title::userCan($action) that seem to be called by userCanRead/userCanEdit... A hook near the end maybe, before 'return true' ? It uses getRestrictions(), which seems to pull something out of the cur_restrictions field, but this is not really documented, what's the format of that column in 'cur', something like edit:user1,user2;move:user3,user2, etc ?
Thanks
-- Sebastien Barre
Sebastien BARRE wrote:
OK, I know one of key feature of a Wiki is "unrestricted access to everyone", but there are some times when you definitely want to have a subpart of a Wiki to be more "private", or "read only", using a more sophisticated scheme than white-lists (no, I don't want to create a separate wiki).
This is not something MediaWiki is designed to support, and attempts to hack it in are very likely to fail. See past list discussions on this topic for eg an attempt which was easily foiled using template inclusions.
If you have private information, do *NOT* put it into a mixed wiki with any public access. This is not supported, not recommended, and generally a bad idea. Your private information *will* be compromised, and you will kick yourself. Please don't do it.
For example, if I check the "Special::Recent Changes", it seems to me that if user can not read a given page P, he should certainly not be able to see the comments that were entered when someone else modified that page P (neither should he be able to see the "diffs"). My fear is that I miss one of the many ways to see the contents of a page.
You will miss many of them, because this is *not* a supported or intended feature. Do not use MediaWiki if this is a requirement for you.
-- brion vibber (brion @ pobox.com)
At 3/7/2005 01:11 AM, Brion Vibber wrote:
Your private information *will* be compromised, and you will kick yourself.
There is no such thing as "secure" anyway, anything can be compromised. Now just how bad can it be compromised on a Wiki I dunno, but I'm not talking credit card numbers here anyway, I'm not even talking putting that in any official release of course, but at least hooks would help. In any case, I'm not sure I need a 30 lines disclaimer, I can take that responsibility :)
On the other end, here is a simple question then: what are functions like userCanRead() and userCanEdit() for, if, at the end of the day, they don't guarantee what they are supposed to do ? Either those 2 functions work, either they don't. They are used already, after all. If they don't, it does not look to me as a deliberate "lack of feature", or "indent not to do it in MediaWiki", but it looks to me like one or more bug(s). Excuse my french, but don't you want that part to be addressed, or at least made more robust ? Now if you are telling me that you don't want more help or more eyes to check the code, then fair enough.
In any case, I should not have used "ACL" in the subject, it is way beyond what I would like to do. What I'm talking about here is nothing more than a small layer on top of the ::userCan() functionality to allow users to be in group(s). The idea is, when ::userCan($action) is called, the restrictions for a user are checked as usual, but an additional check is done (as a hook) to see if he is part of a group, and the restrictions for that group are checked too. I guess a proof of concept could be as simplistic as having that group be a regular user (so that you can set the restrictions of a group just like you set it for a user), and add an extra file/database to link users to that "special user = group". Now that does not look like rocket science to me as an extension, I just need to leverage ::userCan($action), and again, either it works, either it does not, in the later case I'm willing to take a look at it.
-- Sebastien Barre
Sebastien BARRE wrote:
On the other end, here is a simple question then: what are functions like userCanRead() and userCanEdit() for, if, at the end of the day, they don't guarantee what they are supposed to do ? Either those 2 functions work, either they don't.
False dichotomy. ;)
userCanEdit() should 'work' for pretty much all uses; if it doesn't, that's a bug, please report it.
userCanRead() is limited to enforcing $wgWhitelistRead, which is very very limited in what it can do. It's 100% dependent on $wgWhitelistEdit; if nonauthenticated users were allowed to so much as do render page previews on a sandbox they could read the contents of any page in the wiki. Its sole purpose (and it's awkward even for this) is to make a welcome page and the login page reachable before you log in to a private-access wiki.
If anything's editable, *everything* is viewable. By design, everything is supposed to be viewable anyway; anything else is a hack which gives people an opportunity to log in (at which point they are "in" and have full access).
This is deliberate behavior and not a bug.
In any case, I should not have used "ACL" in the subject, it is way beyond what I would like to do. What I'm talking about here is nothing more than a small layer on top of the ::userCan() functionality to allow users to be in group(s).
[snip]
See the user groups support in 1.5. There are bugs to be ironed out still, and the layout of the tables etc will likely change (comma-separated blob fields are a pain in the butt to work with).
-- brion vibber (brion @ pobox.com)
At 3/7/2005 02:23 AM, Brion Vibber wrote:
False dichotomy. ;)
But at least I got your attention :)
If anything's editable, *everything* is viewable. By design, everything is supposed to be viewable anyway; anything else is a hack which gives people an opportunity to log in (at which point they are "in" and have full access).
Allright, allright, you almost convinced me :)
Now let's go the opposite way then: to protect a part of my Wiki, I would have to actually create a second Wiki for the private part, and protect it with some other mechanism, say .htaccess / mod_auth. Now how much interaction can I get between the public and the private Wiki. Can I: - access images and pages from one to the other using Wiki links (interwiki ?) - share skins - share extensions
See the user groups support in 1.5. There are bugs to be ironed out still, and the layout of the tables etc will likely change
Good. Looks nice. I nead to protect from "reading", so it won't solve my issue, but still, it is nice.
-- Sebastien Barre
I've added a field to mw_user that is membership type: an enum with 'non-member', 'supporter', 'member', 'director'. Only the latter two are allowed to view certain content. I hacked the Security extension to do that. Pages with <security></security> cause the Security extension to check the membership type of the current user and display or not accordingly.
Certainly not 128-bit DES, nor even a full ACL implementation, but enough to allow members to view each other's personal info (phone, address, interests, etc.) without letting the whole world in on it.
:::: News is what powerful people don’t want you to hear; everything else is just publicity. -- Bill Moyers :::: Jan Steinman http://www.Bytesmiths.com/Van
Jan Steinman wrote:
I've added a field to mw_user that is membership type: an enum with 'non-member', 'supporter', 'member', 'director'. Only the latter two are allowed to view certain content. I hacked the Security extension to do that. Pages with <security></security> cause the Security extension to check the membership type of the current user and display or not accordingly.
Certainly not 128-bit DES, nor even a full ACL implementation, but enough to allow members to view each other's personal info (phone, address, interests, etc.) without letting the whole world in on it.
Would you mind sending me a copy of that extension to try poking some holes in it?
-- brion vibber (brion @ pobox.com)
On 11 Mar 2005, at 16:10, Brion Vibber wrote:
Jan Steinman wrote:
I've added a field to mw_user that is membership type: an enum with 'non-member', 'supporter', 'member', 'director'. Only the latter two are allowed to view certain content.
Would you mind sending me a copy of that extension to try poking some holes in it?
Not at all -- as soon as I finish implementing it! (blush :-)
It was working, then I thought it would be nice to make it fully general, with an arbitrary set for s_mem_type, and an intersecting set that could be set in LocalPreferences.php, or even via a nice interface. Now it doesn't work any more. :-(
I always think about CVS just after I make that destabilizing change... like the mechanic's rule: "Turn 'till it strips, then back off a quarter."
:::: ECONOMIST: a person who, upon encountering an auditorium containing 40,000 destitute, unemployed people and Bill Gates, says, “On average, I see a room full of millionaires!” :::: Jan Steinman http://www.Bytesmiths.com/Van
Sebastien BARRE wrote:
Now let's go the opposite way then: to protect a part of my Wiki, I would have to actually create a second Wiki for the private part, and protect it with some other mechanism, say .htaccess / mod_auth. Now how much interaction can I get between the public and the private Wiki. Can I: - access images and pages from one to the other using Wiki links (interwiki ?)
You can use interwiki links to link pages between the two.
For images, you might try the shared upload directory support (which use use to make Wikimedia Commons a central image repository accessible from all our projects). You might also be able to get away with just sharing an upload path/directory, though this could lead to some inconsistencies in the image table if you upload an image with the same name in both places.
- share skins - share extensions
These are code outside of the wiki, so naturally can be shared.
-- brion vibber (brion @ pobox.com)
mediawiki-l@lists.wikimedia.org