Hello everyone,
I spent the last weeks researching lightly on the permissions situation at MediaWiki and I found out the following -
a) MediaWiki is not made for permissions, however
b) MediaWiki starts to enter the corporate world, so extensions implementing permissions start to appear, but
c) Because MediaWiki isn't uniformly developed (eg. not all reads go over a read class, etc.) this isn't working very well.
While I fully respect a), I see the reasons behind b), because our company (50 people), looking for a straight almost-turn-key-out-of-the-box intranet solution, chose MediaWiki in order to capitalize on the experience people have made with Wikipedia.
Having the treind, described in b), could somebody explain in a calm, non-partisan way if c) is true and if there is a honest and stable mood in this direction, or we should, generally speaking, forget it?
If the answer is positive, we are ready to contribute.
Regards, Iv
2008/11/14 Iv Ray pobox@verysmall.org:
Hello everyone,
I spent the last weeks researching lightly on the permissions situation at MediaWiki and I found out the following -
a) MediaWiki is not made for permissions, however
b) MediaWiki starts to enter the corporate world, so extensions implementing permissions start to appear, but
c) Because MediaWiki isn't uniformly developed (eg. not all reads go over a read class, etc.) this isn't working very well.
What is it precisely you are trying to do? MediaWiki has quite a sophisticated permissions system, the main thing it can't do (at least not reliably) is make different parts of a wiki visible to different people (beyond a simple whitelist). Depending on exactly what you need, you may be able to get the desired functionality using multiple wikis. Also, as it sounds like you're just developing an internal wiki for a small company, how much security do you need? Does it really matter if people are able to read pages they ideally shouldn't be able to?
Thomas Dalton schrieb:
What is it precisely you are trying to do? MediaWiki has quite a sophisticated permissions system, the main thing it can't do (at least not reliably) is make different parts of a wiki visible to different people (beyond a simple whitelist). Depending on exactly what you need, you may be able to get the desired functionality using multiple wikis. Also, as it sounds like you're just developing an internal wiki for a small company, how much security do you need? Does it really matter if people are able to read pages they ideally shouldn't be able to?
There are items, which management, for instance, does not want available to everyone, while in preparation. It is not about things being secret. Rather about things being presented at a given time, in a given shape. A reasonable policy for a proper internal communication.
On virtually every page of a MediaWiki permissions related module there is a red message that whoever needs per page permissions should look for another system.
Some modules providing permissions per namespace seem quite OK, however closer look shows that in some cases the namespaced pages escape the protection, i.e. in places like "resently modified pages", etc. My question is - is there an effort under way to close these gaps and an estimation of the work needed?
Iv.
Iv Ray wrote:
Thomas Dalton schrieb:
What is it precisely you are trying to do? MediaWiki has quite a sophisticated permissions system, the main thing it can't do (at least not reliably) is make different parts of a wiki visible to different people (beyond a simple whitelist). Depending on exactly what you need, you may be able to get the desired functionality using multiple wikis. Also, as it sounds like you're just developing an internal wiki for a small company, how much security do you need? Does it really matter if people are able to read pages they ideally shouldn't be able to?
There are items, which management, for instance, does not want available to everyone, while in preparation. It is not about things being secret. Rather about things being presented at a given time, in a given shape. A reasonable policy for a proper internal communication.
On virtually every page of a MediaWiki permissions related module there is a red message that whoever needs per page permissions should look for another system.
Some modules providing permissions per namespace seem quite OK, however closer look shows that in some cases the namespaced pages escape the protection, i.e. in places like "resently modified pages", etc. My question is - is there an effort under way to close these gaps and an estimation of the work needed?
Iv.
MediaWiki is primarily developed for sites like those operated by Wikimedia and Wikia, where either the whole site is viewable, or almost none of it is. As far as I know, there is no effort, besides any development work on the various existing extensions, that is working toward such restrictions. There are some efforts to make the UI code more separate from the backend code, which could help with this, though I don't believe that permissions is one of the main reasons for it. To fully close all the potential gaps would probably require substantial work, and there's no guarantee that any changes to core code that may be necessary won't be broken by updates in future versions.
For what you want, it would probably be better and far easier to use 2 separate wikis - like a management wiki for the hidden stuff and another wiki that has most of the content.
Alex schrieb:
MediaWiki is primarily developed for sites like those operated by Wikimedia and Wikia, where either the whole site is viewable, or almost none of it is.
I understand that, per my initial post.
As far as I know, there is no effort, besides any development work on the various existing extensions, that is working toward such restrictions.
Right, I just wonder why so many extensions are developed, which, in fact, do not provide what they are written for. If all these people would combine their effort to fix MediaWiki, a more acceptable result might come out of it.
There are some efforts to make the UI code more separate from the backend code, which could help with this, though I don't believe that permissions is one of the main reasons for it.
Right, there are many reason for a good software design, and a good design will make implementing permissions (and other features) easier.
To fully close all the potential gaps would probably require substantial work, and there's no guarantee that any changes to core code that may be necessary won't be broken by updates in future versions.
A good design should not break things, at least not between minor releases. Every serious peace of software works in some combination with other, and they do not break each other daily.
For what you want, it would probably be better and far easier to use 2 separate wikis - like a management wiki for the hidden stuff and another wiki that has most of the content.
Yes, this seems a reasonable solution.
Thank you, everyone! Iv
Iv Ray wrote:
Alex schrieb:
MediaWiki is primarily developed for sites like those operated by Wikimedia and Wikia, where either the whole site is viewable, or almost none of it is.
I understand that, per my initial post.
As far as I know, there is no effort, besides any development work on the various existing extensions, that is working toward such restrictions.
Right, I just wonder why so many extensions are developed, which, in fact, do not provide what they are written for. If all these people would combine their effort to fix MediaWiki, a more acceptable result might come out of it.
Because half-fixes are easier than a full one? If you provided a full fix (without breaking anything), it would be accepted, and new code would follow that design. Missing it, each point accessing to the data don't have anything to fix. Also, some of the gaps have been closed (such as addtion of $wgNonIncludableNamespaces).
Duesentrieb's extension did a good job limiting access, but for perfomance problems, core was changed in a breaking it.
There are items, which management, for instance, does not want available to everyone, while in preparation. It is not about things being secret.
Is it so important that nothing can be discovered, then? Getting a piece of text you weren't supposed to read on the search summary isn't so bad if that is going to be published in a few days.
Platonides schrieb:
Because half-fixes are easier than a full one?
Yes, it seems to be a matter of attitude.
If you provided a full fix (without breaking anything), it would be accepted
No one can provide a "full fix", especially without breaking anything, without a community agreement and support of the idea.
Also, some of the gaps have been closed (such as addtion of $wgNonIncludableNamespaces).
Yes. This was my starting point - there is definitely interest and work in this direction, but there isn't even one solution which provides this in a stable way without red warning text.
There are items, which management, for instance, does not want available to everyone, while in preparation. It is not about things being secret.
Is it so important that nothing can be discovered, then? Getting a piece of text you weren't supposed to read on the search summary isn't so bad if that is going to be published in a few days.
Of course, one can endlessly discuss this. It is simply nice to announce things when ready and not have rumors spreading around and people asking questions.
I never said MedaiWiki must address this issue. Just wanted to know how far it is from solving it and what is the mood. The feeling I have is that it is quite far and the mood is not very enthusiastic :)
Thanks, anyway! Iv
Iv Ray wrote:
Platonides schrieb:
Because half-fixes are easier than a full one?
Yes, it seems to be a matter of attitude.
If you provided a full fix (without breaking anything), it would be accepted
No one can provide a "full fix", especially without breaking anything, without a community agreement and support of the idea.
Having that feature is not a target. But it's a common requested featured, and would get accepted. However, don't expect others will actively work to make that.
Wikipedia is about serving people and if some of these people like MediaWiki because of that, and need a couple of features in order to make it usable in their environment, the spirit of serving should, at least, allow that, if not supporting it, which would be, in my opinion, the right approach.
Wikipedia is about making an encyclopedia. The goal of MediaWiki is not making people happy or use it, but to run it on Wikipedia. The fact that it is free, open source and publicly available are just convenient for third parties.
the spirit of serving should, at least, allow that, if not supporting it,
Yes, in spite of what I remarked above, there's ample room for asking improvements and adding fixes for features not needed for Wikipedia.
As I told you, if you manage to "fix" it, you'll almost surely allowed to have incorpored into the software the changes needed. But, easy things, are more likely to get done, and people isn't currently caring so much about it to have it implemented. If you care enough, sure, go for it.
No need to rant about the status quo, unless you're really going to change it.
There are items, which management, for instance, does not want available to everyone, while in preparation. It is not about things being secret. Rather about things being presented at a given time, in a given shape. A reasonable policy for a proper internal communication.
It doesn't sound like you need per page read permissions, it sounds like you need a versioning system. Mark items that aren't ready as draft; or, even better, used the Flagged Revs extension, and mark the item as draft through that.
Per page read restrictions are likely to never be properly supported in the software, and if you *truly* need it, you should look at using a CMS, or a wiki that was designed for this.
V/r,
Ryan Lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Iv Ray wrote:
I spent the last weeks researching lightly on the permissions situation at MediaWiki and I found out the following -
a) MediaWiki is not made for permissions, however
b) MediaWiki starts to enter the corporate world, so extensions implementing permissions start to appear, but
c) Because MediaWiki isn't uniformly developed (eg. not all reads go over a read class, etc.) this isn't working very well.
MediaWiki is designed primarily for situations where reads are available to all, and writes are restricted; sometimes with a requirement to log in before reading.
Other configurations with multiple visibility levels are possible, especially with some unofficial plugins, but we offer no guarantee that they will work reliably, since the system's base architecture isn't designed for it.
It's up to you whether that's an acceptable risk for your usage and your data.
- -- brion
mediawiki-l@lists.wikimedia.org