Related Topics: WebAdmin
TWiki based group authentication is a flexible approach, and detached from user authentication. Users still get authenticated the same way, based on web server authentication (or alternatively it could be cookie based). Certain functions, like performing WebAdmin
functions, or permission to edit certain topics can be restricted based on group authentication.
Group authentication can be made like this (intended as RFC) :
(deleted, superceded by spec below)
- Open question: It makes sense to restict a whole web to be editable only by a certain group or groups. How to define?
- 20 Jul 2000
Concerning the last point: a simple authorization scheme, compatible with present implementation of twiki, is described in UserAuthorizationSchemes
- 04 Sep 2000
Here is the spec for authentication based on groups, intended as an RFC. My goal is to have a flexible and powerful way of allowing and restricting view
of topics, with a selectable granularity (per web or per topic). Ease of use and intuitiveness are important too. (Feedback is appreciated.)
- Access restriction based on groups will be implemented, but use is discouraged unless necessary, because it goes against the free Wiki culture.
- Groups can be defined in addition to users:
- A group is defined as a topic in the TWiki.Main web.
- The topic name ends in ...Group, i.e. TWikiAdminGroup
- A "Set GROUP" bullet line defines the group members. Example:
- Set GROUP = Main.PeterThoeny, Main.NicholasLee, Main.AndreaSterbini
- There are two types of access restrictions:
- Permission to view topics (applicable only if the whole TWiki site is authenticated, i.e. not for this TWiki installation here)
- Permission to change existing topics or new topics
- Access restriction (e.g. view, change, create) can be defined on two levels:
- Access restriction defined in topic
- Access restriction defined in Preferences
- Access restriction defined in topic:
- View permission can be set by a "Set ALLOWTOPICVIEW" bullet line somewhere in the topic (recommended to put at the end of the topic so that it is near the edit link). The line contains one or more users or groups (separated by comma) that have view permission. Example:
- Set ALLOWTOPICVIEW = Main.TWikiAdminGroup
- Change permission (e.g. edit topic or attach file) can be set by a "Set ALLOWTOPICCHANGE" bullet line somewhere in the topic. The line contains one or more users or groups that have change permission. Example:
- Set ALLOWTOPICCHANGE = Main.SomeUser, Main.AnotherUser, Main.SomeGroup, Main.AnotherGroup
- View permission should not be set on a per topic level, it is recommended to set it per web (if at all).
- Of course, group topics in TWiki.Main should be protected so that not anyone can add him/herself to the group Example for the TWikiAdminGroup topic:
- Set ALLOWTOPICCHANGE = Main.TWikiAdminGroup
- Access restriction defined in Preferences:
- Preference variables to deny or permit access to view, change or create topics are defined on site level (TWikiPreferences) and on web level (WebPreferences).
- The value is a comma separated list of topic names (user topics and group topics)
DENYWEBVIEW preference variable defines persons or groups who are not allowed to view topics. Example:
* Set DENYVIEW = Main.TWikiGuest
ALLOWWEBVIEW preference variable defines persons or groups who are allowed to view topics. Example:
* Set ALLOWVIEW = Main.TWikiAdminGroup, Main.AlbertEinstein
DENYWEBCHANGE preference variable defines persons or groups who are not allowed to change or create topics.
ALLOWWEBCHANGE preference variable defines persons or groups who are allowed to change or create topics.
- Implicit sequence of checking access permissions:
DENYTOPIC... topic variable overrides the
DENYWEB... preference variable.
DENY... variable. Deny access if person is in list.
ALLOWTOPIC... topic variable overrides the
ALLOWWEB... preference variable.
- If exists:
- Check if person is in list. Grant access if it is, else deny
- If line does not exists:
Ideas for implementation:
- Create subroutine
checkAccessPermission( $theAccessType, $theUserName, $theTopicText, $theTopicName, $theWebName) in
- The routine does the implicit sequence of checking access permissions.
- Used by the
rdiff scripts with
$theAccessType = "view"
- Used by the
attach scripts with
$theAccessType = "change"
- Used by the
attach scripts with
$theAccessType = "create" in case topic does not exist.
- The routine should be generic so that a new
$accessType can be defined without changing the code. Examples are "synchronize" for replication, "delete" to delete topics or webs.
- View permissions need to be considered for topic
%INCLUDE%, i.e. user has access to view the topic where
%INCLUDE% is standing, but not the included topic.
- How to handle mailnotify? Restrict by user?
- How to restrict overriding of
DENY... site preferences? We could use AlWilliams' idea in LockedPages.
I will start working on the implementation soon. Feedback? Ideas?
- 22 Sep 2000 (amended 23 Oct 2000)
Regarding Implicit sequence of checking access permissions
How about making the sequence explicitly specifiable as in apache's config?
deny from all
allow from Main.ManpreetSingh
allow from all
deny from Main.ManpreetSingh
etc. so that different kind of access can be specified more easily.
Or, how about looking at the various ways secure OSes specify how to grant/deny permissions?
How about ACLs? (though I myself don't know a lot about them yet )? etc.
- 22 Sep 2000
A lot of what a Wiki does is common with WebDAV
has an ACL based access control draft proposal in works.
- 23 Sep 2000
We can use some ideas of WebDAV
's ACL proposal. It is kind of a complex proposal, for TWiki it makes sense to use just a small subset initially and extend it over time. At some point in the future we can extend TWiki to be a TWikiWebDavServer
- 23 Sep 2000
First preparation step is done, see also BetterTWikiTagTemplateProcessing
: In the preferences it is now possible to restrict overriding of
variables by setting a
variable containing a list of variables that may not be overridden. Example:
- Set FINALPREFERENCES = WEBTOPICLIST, DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE, ALLOWWEBCHANGE
- Set DENYWEBVIEW =
- Set ALLOWWEBVIEW =
- Set DENYWEBCHANGE = TWikiGuest
- Set ALLOWWEBCHANGE = TWikiAdminGroup
- Set ALLOWTOPICCHANGE = TWikiAdminGroup
- Create a new "module"
wikiaccess.pm that handles access control. (It can be OO'zed at some later time once we have the modularization in place.)
- Work on the
- 28 Sep 2000 (amended 23 Oct 2000)
One of the Wikis I saw someplace had the concept of differentiating between appends (change), edits and creates. If append and edit are differentiated, we could allow, for example, guests to be only able to append to an existing topic. This would make the topic work like a bulletin board.
- 28 Sep 2000
A text append mode is a logical extension to the TWikiAccessControl
property and could be easily added by defining a new type
of access restriction:
- Permission to append text to topics, as opposed to:
- Permission to change topics (edit, attach)
Is also a question of user interface. Add a Append
link at the bottom of the page?
Regarding definition of a group and topic access restriction: I created two test topics to show that, TWikiAdminGroup
. Please have a look at these topics and let us know here what you think about the syntax.
- 28 Sep 2000
You could extend the Append idea to allow appends at various
places in the page. There could be a special tag that you could
embed in the page. When you click on it, text ends up being appended
at that point. Each append tag could have optional attributes: an ID so that you could have multiple append points on a single page, an order attribute: "append before" (for oldest comment first ordering) or "append after" (for oldest comment last ordering), and other attributes to be defined in the future.
- 29 Sep 2000
A question: Why are we re-doing the authentication stuff of apache?
We already rely on apache to authenticate the user ...
Is'nt it easier to add a tool to manage .htaccess and .htgroup files?
- 29 Sep 2000
Well, authentication by the apache server is useful but access restriction using the .htaccess file is rather bad: you cannot
easily allow view but not editing (I did it using Apache's Rewrite Rules, but it is quite painful).
Bytheway, I'm developing a mod_perl module to handle apache authetications so that I can check them against an existing sql database. I think that the same modulus could be used to replace the .htaccess file, so that one can use a complete wiki approach to usernames/password or restrict access on a per web/per page/per user basis. If someone is interested I can post the results.
However, with this approach one cannot forbid searches to enter directories, to accomplish this goal one has also to modify the scripts.
Concerning the append question: I partially solved it using subwebs, as described in the WebTeach
An elegant way of adding a note to a given portion of a text without editing the text itself or embedding buttons could be the following:
Add an empty (small?) textarea at the bottom of the page. One can select a portion of the text and paste it into the textarea (the same one does with the signature). Then two buttons permit to add a note before or after the text. After that, one enters the text as usual (preferably in a different window, or in the same textarea as before, so to have the original portion of the text at hand). Finally, having the information of the previous pasted text (and hoping it occours only once) the note is added at the end (or in a sepatate reply topic) and a link is placed in the right position.
- 30 Sep 2000
Using a textarea and asking the users to paste into it in order to
append to text in the middle of a msg, is probably too much to
ask for lots of the user community -- at least for mine. It needs to
simple and foolproof: click here, fill in box, click submit.
It would be nice to automate the signature append too as part
of the append here operation.
Is the "Append Here" function something could be implemented using TWikiPluginAPI
- 01 Oct 2000
I think that an automatic appending of signatures is feasible, but you have to remove it when not commenting.
In my opinion, if you are using twiki as a "message board", you should have a look at my "threaded" extension (see WebTeach
), it is quite a click-type-submit solution.
- 01 Oct 2000
I was thinking of something very similar to what you described.
I was assuming that the automatic signature appending would
only be turned on when using this append-here function.
While you could use it for a message board, it seems like it
would have other uses too. It could be
implemented with a generalized function -- the click causes the current page text, user login name, etc. to be piped to an application that could then: ask for user input, process it, return an updated version of the page text.
looks interesting but when I try to follow the link
on the WebTeach
page, it asks for a user name/password.
- 02 Oct 2000
Sorry, I'm actually working to WebTeach
since it should "open" in a few day and it changes everyday.
I'll update the link so to allow people to read about the project without actually entering the site.
- 02 Oct 2000
I implemented authentication based on groups following the above guidelines. You can find it on WebTeach
- 18 Oct 2000
I will look at your contribution Franco. As mentioned I am currently working on the implementation, and in fact it is almost done, just some more finishing touches before it goes into the Alpha repository.
- 21 Oct 2000
First step of access control is implemented and commited to TWikiAlphaRelease
- Changed script files
- New template files
It is possible to deny and grant topic changes in any web by specifying the following in the WebPreferences
- Users or groups who are not / are allowed to change topics in the Codev web: (See TWikiAccessControl)
- Set DENYWEBCHANGE = <list of users and/or groups>
- Set ALLOWWEBCHANGE = <list of users and/or groups>
A topic itself can override the access controls defined in WebPreferences
- Users or groups allowed to change the topic:
- Set ALLOWTOPICCHANGE = <list of users and/or groups>
Groups are defined in the Main web as group topics. A group topic name ends with "Group", i.e. TWikiAdminGroup
. The group topic itself should define two Sets:
- Set GROUP = <list of users and/or groups>
- Set ALLOWTOPICCHANGE = <name of topic>
GROUP defines the members of a group. It is a comma delimited list of users.
ALLOWTOPICCHANGE makes sure that only members of the group can change the topic, so that other people cannot add themselfs to the group
Groups can be nested; recursion is prevented.
topic in the TWiki web should describe access control in detail (doc is pending)
- Document access control in TWikiAccessControl
- Implement view access control (already done in
wikiaccess.pm; needs to be added to
- Test more
- 23 Oct 2000
I forgot to add
to the TWikiAlphaRelease
CVS repository - sorry. Has been done now.
Also, test change permission in the TWiki.Test web:
- 23 Oct 2000
I set the classification to FeatureDone
protection based on groups has been implemented and is part of the 01 Dec 2000 production release.
One pending feature is to read
protect pages, follow up in ReadAccessPermission
- 26 Nov 2000
I implemented a read access restriction for a whole
TWiki web. It is now possible to place restrictions of who is allowed to view a TWiki web.
Define one or both of these variable in the WebPreferences
- Set DENYWEBVIEW = < list of users and groups >
- Set ALLOWWEBVIEW = < list of users and groups >
Some remarks on read access restriction:
- Read access restriction only works if the view script is authenticated, that means that users need to log on also just to read topics. TWiki Installation has more on basic authentication based on the
- There is a workaround if you prefer to to have unrestricted access to view topics located in normal webs, and to authenticate users only for webs where view restriction is enabled:
- Leave the
view script non authenticated in the
- Enable the
$doRememberRemoteUser flag in
wikicfg.pm as described in TWiki Authentication. TWiki will now remember the IP address of an authenticated user.
- Copy the
view script to
viewauth (or better, create a symbolic link)
- Enable authentication for the
viewauth script in the
- When a user accesses a web where you enabled view restriction, TWiki will redirect from the
view script to the
viewauth script once (this hapens only if the user has never edited a topic). Doing so will ask for authentication. The
viewauth script shows the requested topic if the user could log on and if the user is authorized to see that web.
- If you enable view restriction for a web, it is recommended to restrict search "all webs" from searching this web. Enable this restriction with the
NOSEARCHALL variable in its WebPreferences, like:
- It is not recommended to restrict view access to individual topics since all content is searchable within a web.
- The view restriction is not suitable for very sensitive content since there is a way to circumvent the read access restriction.
Commited to TWikiAlphaRelease
and made a TWikiBetaRelease
- 20 Jan 2001