none

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 &amp; 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 &amp; 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.