diff options
| -rw-r--r-- | TWiki/TWikiAccessControl.mdwn | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/TWiki/TWikiAccessControl.mdwn b/TWiki/TWikiAccessControl.mdwn index 9d1dbcd7..a7bd6709 100644 --- a/TWiki/TWikiAccessControl.mdwn +++ b/TWiki/TWikiAccessControl.mdwn @@ -8,18 +8,18 @@ _Restricting read and write access to topics and webs, by users and groups_ ## <a name="Overview"> Overview </a> -[[TWikiAccessControl]] allows you restrict access to single topics and entire webs, by individual user and by user groups, in three main areas: view; edit & attach; and rename/move/delete. These controls, combined with [[TWikiDocumentation]], let you easily create and manage an extremely flexible, fine-grained privilege system. +[[TWikiAccessControl]] allows you restrict access to single topics and entire webs, by individual user and by user groups, in three main areas: view; edit & attach; and rename/move/delete. These controls, combined with [[TWikiUserAuthentication]], let you easily create and manage an extremely flexible, fine-grained privilege system. ## <a name="An_Important_Control_Considerati"> An Important Control Consideration </a> -Open, freeform editing is the essence of the %TWIKIWEB%.WikiCulture - it's what makes TWiki different and often more effective than other collaboration tools. So, it is strongly recommended that decisions to restrict read or write access to a web or a topic are made with care. Experience shows that _unrestricted write access_ works very well because: +Open, freeform editing is the essence of the [[WikiCulture]] - it's what makes TWiki different and often more effective than other collaboration tools. So, it is strongly recommended that decisions to restrict read or write access to a web or a topic are made with care. Experience shows that _unrestricted write access_ works very well because: * Peer influence is enough to ensure that only relevant content is posted. * Peer editing - the ability to rearrange anything on a page - keeps topics focussed. * All content is preserved under revision control. - * Edits can be undone by the %MAINWEB%.TWikiAdminGroup (the default administrators group; see Managing Groups). + * Edits can be undone by the %MAINWEB%.TWikiAdminGroup (the default administrators group; see #ManagingGroups). * Users are encouraged to edit and refactor (condense a long topic), since there's a safety net. As a collaboration guideline: @@ -33,9 +33,9 @@ Access control is based on users and groups. Users are defined by their [[WikiNa ### <a name="Managing_Users"> Managing Users </a> -A user is created by with the [TWikiRegistration](%SCRIPTULRPATH%/view%SCRIPTSUFFIX%/TWiki/TWikiRegistration) form. The process generates a topic in the %MAINWEB% web in the new user's [[WikiName]]. The default visitor name is %MAINWEB%.TWikiGuest. +A user is created by with the [[TWikiRegistration]] form. The process generates a topic in the %MAINWEB% web in the new user's [[WikiName]]. The default visitor name is %MAINWEB%.TWikiGuest. -* Users can be authenticated using Basic Authentication or SSL. [[TWikiDocumentation]] is required in order to track user identities. +* Users can be authenticated using Basic Authentication or SSL. [[TWikiUserAuthentication]] is required in order to track user identities. <a name="ManagingGroups"></a> @@ -125,13 +125,13 @@ You can define restrictions of who is allowed to view a %WIKITOOLNAME% web. ### <a name="Known_Issues"> Known Issues </a> * The view restriction is not suitable for very sensitive content since there is a way to circumvent the 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. [[TWikiDocumentation]] has more on Basic Authentication based on the <code>**.htaccess**</code> file. +* Read access restriction only works if the view script is authenticated, that means that users need to log on also just to read topics. [[TWikiInstallationGuide]] has more on Basic Authentication based on the <code>**.htaccess**</code> file. #### <a name="Selective_Unrestricted_Web_Acces"> Selective Unrestricted Web Access </a> * There is a workaround if you prefer to have unrestricted access to view topics located in normal webs, and to authenticate users only for webs where view restriction is enabled: 1. **Omit** the <code>**view**</code> script from the `.htaccess` file. - 2. **Enable** the <code>**$doRememberRemoteUser**</code> flag in <code>**lib/wikicfg.pm**</code> as described in [[TWikiDocumentation]]. %WIKITOOLNAME% will now remember the IP address of an authenticated user. + 2. **Enable** the <code>**$doRememberRemoteUser**</code> flag in <code>**lib/TWiki.cfg**</code> as described in [[TWikiUserAuthentication]]. %WIKITOOLNAME% will now remember the IP address of an authenticated user. 3. **Copy** the <code>**view**</code> script to <code>**viewauth**</code> (or better, create a symbolic link) 4. **Add** <code>**viewauth**</code> to the list of authenticated scripts in the .htaccess file. * When a user accesses a web where you enabled view restriction, %WIKITOOLNAME% will redirect from the `view` script to the `viewauth` script once (this happens 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. |