Difference: TWikiAccessControl (32 vs. 33)

Revision 332006-10-13 - TWikiContributor

Line: 1 to 1
	On this page: An Important Control Consideration Permissions settings of the webs on this TWiki site Authentication vs. Access Control Users and Groups Managing Users Managing Groups The Super Admin Group Restricting Access Controlling access to a Web Controlling access to a Topic Allowing public access to specific topics in a restricted web Empty values in access control variables Securing File Attachments Controlling who can manage top-level webs How TWiki evaluates ALLOW/DENY settings Allowing web creation by user mapping manager User masquerading Dynamic access control Example 1 - restriction based on topic name Example 2 - restriction based on form field Dynamic access control in accessing a different web's topic Topic level dynamic access control Dynamic access control and user masquerading Avoiding vulnerability Disabling dynamic access control Access control and INCLUDE Customizing "access denied" message Custom user/group notations Access Control quick recipes Restrict Access to Whole TWiki Site Authenticate and Restrict Selected Webs Only Hide Control Settings Obfuscating Webs Read-only Skin Mode Configuring access control for topics of a certain name in all webs
Line: 66 to 66
	The Super Admin Group
Changed:
< <	By mistyping a user or group name in the settings, it's possible to lock a topic so that no-one can edit it from a browser. To avoid this, add the WikiNames of registered administrators to the super admin group topic called `TWikiAdminGroup`. The name of this topic is defined by the {SuperAdminGroup} configure setting. Example group setting:
> >	By mistyping a user or group name in the settings, it's possible to lock a topic so that no-one can edit it from a browser. To avoid this, add the WikiNames of registered administrators to the super admin group topic called `TWikiAdminGroup`. The name of this topic is defined by the {SuperAdminGroup} configure setting. Example group setting:
	`Set GROUP= Main.ElizabethWindsor, Main.TonyBlair` Restricting Access
Line: 75 to 75
	Restricting VIEW blocks viewing and searching of content. Restricting CHANGE blocks creating new topics, changing topics or attaching files.
Deleted:
< <	Restricting RENAME controls who is allowed to rename, move or delete a topic. To rename, move or delete a topic, the user also also needs VIEW and CHANGE permission. They also need CHANGE access to change references in any referring topics (though the rename can proceed without this access), and CHANGE access to the target topic. Restricting MANAGE controls access to certain management functions, such as 'create web'. It must be set in the TWiki web.
	Controlling access to a Web
Changed:
< <	You can define restrictions of who is allowed to view a PlanetoWiki web. You can restrict access to certain webs to selected Users and Groups, by:
> >	You can define restrictions on who is allowed to view a PlanetoWiki web. You can restrict access to certain webs to selected Users and Groups, by:
	authenticating all webs and restricting selected webs: Topic access in all webs is authenticated, and selected webs have restricted access. authenticating and restricting selected webs only: Provide unrestricted viewing access to open webs, with authentication and restriction only on selected webs.
Line: 91 to 88
	`Set ALLOWWEBVIEW = < comma-delimited list of Users and Groups >` `Set DENYWEBCHANGE = < comma-delimited list of Users and Groups >` `Set ALLOWWEBCHANGE = < comma-delimited list of Users and Groups >`
Deleted:
< <	`Set DENYWEBRENAME = < comma-delimited list of Users and Groups >` `Set ALLOWWEBRENAME = < comma-delimited list of Users and Groups >`
	Be careful with empty values for any of these. In older versions of TWiki, `Set ALLOWWEBVIEW =`
Line: 102 to 97
	Controlling access to a Topic
Changed:
< <	You can define these settings in the WebPreferences topic, preferable towards the end of the topic:
> >	You can define these settings in any topic, preferable towards the end of the topic:
	`Set DENYTOPICVIEW = < comma-delimited list of Users and Groups >` `Set ALLOWTOPICVIEW = < comma-delimited list of Users and Groups >` `Set DENYTOPICCHANGE = < comma-delimited list of Users and Groups >` `Set ALLOWTOPICCHANGE = < comma-delimited list of Users and Groups >`
Deleted:
< <	`Set DENYTOPICRENAME = < comma-delimited list of Users and Groups >` `Set ALLOWTOPICRENAME = < comma-delimited list of Users and Groups >`
	Remember when opening up access to specific topics within a restricted web that other topics in the web - for example, the WebLeftBar - may also be accessed when viewing the topics. The message you get when you are denied access should tell you what topic you were not permitted to access.
Line: 131 to 124
	RewriteEngine on RewriteCond %{REQUEST_URI} !^/+twiki/+pub/+TWiki/+.+ RewriteRule ^/+twiki/+pub/+([^/]+)/+((([^/]+)/+)+)(.+) /twiki/bin/viewfile/$1/$4?filename=$5 [L,PT]
Changed:
< <	</verbatim
> >
	That way all the controls that apply to the topic also apply to attachments to the topic. Other types of webserver have similar support. *Note:* Images embedded in topics will load much slower since each image will be delivered by the `viewfile` script.
Added:
> >	Controlling who can create top-level webs Top level webs are a special case, because they don't have a parent web with a WebPreferences. So there has to be a special control just for the root level. You can define these settings in the Main.%TWIKIPREFSTOPIC% topic, preferable towards the end of the topic: `Set DENYROOTCHANGE = < comma-delimited list of Users and Groups >` `Set ALLOWROOTCHANGE = < comma-delimited list of Users and Groups >` Note that you do not require `ROOTCHANGE` access to rename an existing top-level web. You just need `WEBCHANGE` in the web itself.
	How TWiki evaluates ALLOW/DENY settings
Changed:
< <	When deciding whether to grant access, TWiki evaluates the following rules in order (read from the top of the list; if the logic arrives at PERMITTED or DENIED that applies immediately and no more rules are applied). You need to read the rules bearing in mind that VIEW, CHANGE and RENAME access may be granted/denied separately.
> >	When deciding whether to grant access, TWiki evaluates the following rules in order (read from the top of the list; if the logic arrives at PERMITTED or DENIED that applies immediately and no more rules are applied). You need to read the rules bearing in mind that VIEW and CHANGE access may be granted/denied separately.
	If the user is a super-user access is PERMITTED. If DENYTOPIC is set to a list of wikinames
Line: 189 to 189
	Hide Control Settings
Changed:
< <	*Tip:* To hide access control settings from normal browser viewing, place them in HTML comment markers.
> >	*Tip:* To hide access control settings from normal browser viewing, you can put them into the topic-local settings. You can access those settings via the "More" screen, as explained in TWikiVariables. Alternatively, place them in HTML comment markers, but this exposes the access setting during ordinary editing.
	`<!--`

View topic | History: r42 < r41 < r40 < r39 | More topic actions...

Copyright © 1999-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding PlanetoWiki? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.TWikiAccessControl.

Difference: TWikiAccessControl (32 vs. 33)

Revision 332006-10-13 - TWikiContributor

The Super Admin Group

Restricting Access

Controlling access to a Web

Controlling access to a Topic

Controlling who can create top-level webs

How TWiki evaluates ALLOW/DENY settings

Hide Control Settings