create new tag
, view all tags

Hostile Users

What about hostile users?

This isn't really a brainstorming feature or idea, more of a FAQ... But I didn't find the FAQ, so I apologize if this is misplaced here.

Here is my question: can Wiki be used for controversial topics? Take, for example, the battle between the Church of Emacs vs. the True Church of Vi. What I would like is to provide a space for vi users to provide testimony about the strength of the vi gospel, without allowing militant emacs fanatics to destroy or deface the testimonials.

Specifically, what I am looking for is a setup in which new users can register themselves automatically, and they will obtain a set of permissions that allows them to work on one specific topic. It doesn't have to be one topic, actually, but a clearly separated area in the Wiki hierarchy.

I do not mind if emacs disciples pretend to be vi users and register and create their own, misguided testimonials, but I want complete separation between registered users. In a way, what I want is similar to a Unix box where all homedirectories are set to go-w.

Is such a setup possible - and how hard would it be?

-- TWikiGuest - 04 May 2000

Dear guest, Wiki systems count on trust. Everybody can create and change pages. There is no exclusion by design. Previous topic revisions are accessible in case something got overwritten by mistake or by purpose.

-- PeterThoeny - 04 May 2000

Peter, thanks for your reply.

I realize that the revision mechanisms allows me to restore pages. But that won't do me any good since one would have to watch the vi pages constantly to see when the Emacs fanatics strike. True vi users, however, are productive people and can't afford to watch and patch all the time, even with the support of automatic email notification (which isn't even possible for a specific topic, right?).

I guess that Twiki won't be for me under these circumstances. Maybe some other clone from the WikiClonesDirectory will provide the features I need. I remember reading about clones that provide Unix-like access control with different classes of users, maybe I find something. However, it seems that those aren't as actively maintained. Thanks anyway.

-- TWikiGuest - 04 May 2000

At some stage I was planning to develop some authorisation code for TWiki. Read /Write access control on a per file or Web basis.

-- NicholasLee - 06 May 2000

That would be great. Ideally, it should be dynamic in the sense that registering a new user will automatically create a new "domain" in which the user has sufficient access privileges and (at least initially) separation from other users. I mean this as opposed to a scheme where the access control domain is assigned statically before or after a new user creates content.

-- TWikiGuest - 07 May 2000

In an effort to isolate two groups in my site I created a second TWiki installation. Both of them are run from the same apache server using different authentication groups. Most of the people are in both groups (the vi/emacs agnostics) but some people (the vi luddites) are only listed in one group to prevent them from gaining access to information they shouldn't have.

This is described in a little more detail in BetterFileLocking. -- JohnAltstadt - 07 Jul 2000

Would this sort of scheme help you keep your users from fighting?

-- JohnAltstadt - 06 May 2000

While such a bipartitioning would help, I don't think it would be scalable enough. Let's extend my (hypothetical) emacs/vi example quantum-mechanically. Suppose users are initially in an undefined state; only through observation (i.e., my reading of their contributions) can I say to which group they possibly belong. In short, because of the uniqueness of the user's quantum states (Heisenberg's uncertainty principle) I think I do need a user-centered authorization scheme.

-- TWikiGuest - 07 May 2000

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2001-12-29 - TWikiBot
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.