Brion Vibber wrote:
Jean-Christian Imbeault wrote:
Oh, and I do realize that ACLs go against the spirit of a wiki. It's just that we would like to use mediawiki internally but some information must not be viewed by certain employees (legal reasons, NDAs, etc ...)
MediaWiki is *not* designed for sensitive data.
I strongly advise you not to attempt to use MediaWiki for material that you are legally obligated to keep private.
I'm trying to understand the reason for this recommendation. Is it because
-- Luis Casillas
On Aug 12, 2004, at 10:10 AM, Luis Casillas wrote:
Brion Vibber wrote:
Jean-Christian Imbeault wrote:
Oh, and I do realize that ACLs go against the spirit of a wiki. It's just that we would like to use mediawiki internally but some information must not be viewed by certain employees (legal reasons, NDAs, etc ...)
MediaWiki is *not* designed for sensitive data.
I strongly advise you not to attempt to use MediaWiki for material that you are legally obligated to keep private.
I'm trying to understand the reason for this recommendation. Is it because
Ooops, accidental send. What I meant to ask is whether there is some intrinsic design characteristic that makes it unsuitable for such use, or whether it's a matter of implementation details that development doesn't address because the software is not intended for that.
-- Luis Casillas casillas@mercedsystems.com
Luis Casillas wrote:
Ooops, accidental send. What I meant to ask is whether there is some intrinsic design characteristic that makes it unsuitable for such use, or whether it's a matter of implementation details that development doesn't address because the software is not intended for that.
While it's possible to hack in some more access control, the wiki is designed to assume that all pages are always *readable*. The existing read whitelist is an unsupported hack and I guarantee there are holes in it.
If someone wants to use our software for something where there may be legal liability in allowing unauthorized people to access material on the wiki, they do so at their sole risk and are responsible for finding and plugging any holes in their system.
The best way is to put the restricted material _somewhere else_ and reference it, or to use HTTP authentication to restrict access to the entire wiki.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Luis Casillas wrote:
Ooops, accidental send. What I meant to ask is whether there is some intrinsic design characteristic that makes it unsuitable for such use, or whether it's a matter of implementation details that development doesn't address because the software is not intended for that.
While it's possible to hack in some more access control, the wiki is designed to assume that all pages are always *readable*. The existing read whitelist is an unsupported hack and I guarantee there are holes in it.
If someone wants to use our software for something where there may be legal liability in allowing unauthorized people to access material on the wiki, they do so at their sole risk and are responsible for finding and plugging any holes in their system.
The best way is to put the restricted material _somewhere else_ and reference it, or to use HTTP authentication to restrict access to the entire wiki.
Or one can join the development team and implement a real restriction system :o)
You will be most welcome to do.
On Aug 14, 2004, at 3:04 PM, Ashar Voultoiz wrote:
Or one can join the development team and implement a real restriction system :o)
Well, for better or worse, I realized that I can get away very well without one. What I really need is a mechanism to export static HTML pages from a site. I expect I'll have to write one that suits my needs, though it won't happen until a few weeks from now at the earliest.
-- Luis Casillas casillas@mercedsystems.com
mediawiki-l@lists.wikimedia.org