Difference: TWikiUserAuthentication (1 vs. 28)

Revision 282014-07-13 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 8 to 8
 

Overview

Changed:
<
<
Authentication, or "loging in", is the process by which a user lets TWiki know who they are.
>
>
Authentication, or "logging in", is the process by which a user lets TWiki know who they are.
  Authentication isn't just about access control. TWiki uses authentication to identify users so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of ghosts.
Line: 89 to 89
 

Apache Login (select TWiki::LoginManager::ApacheLogin in configure)

Changed:
<
<
Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.
>
>
Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which the webserver passes to TWiki when you enable authentication in the webserver (as described in RFC 3875 - "The Common Gateway Interface v1.1").
 
Changed:
<
<
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules, such as mod_auth_ldap or mod_auth_mysql, you can just plug in directly to them.
>
>
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules, such as mod_authnz_ldap or mod_authn_dbd, you can just plug in directly to them.
  The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.

Revision 272013-06-28 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 8 to 8
 

Overview

Changed:
<
<
Authentication, or "login", is the process by which a user lets TWiki know who they are.
>
>
Authentication, or "loging in", is the process by which a user lets TWiki know who they are.
 
Changed:
<
<
Authentication isn't just to do with access control. TWiki uses authentication to identify users, so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of shadows.
>
>
Authentication isn't just about access control. TWiki uses authentication to identify users so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of ghosts.
 
Changed:
<
<
TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.
>
>
TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access or only for changes. Authentication is also essential for access control.
  Quick Authentication Test - Use the %USERINFO% variable to return your current identity:
Changed:
<
<
TWiki user authentication is split into four sections; password management, user mapping, user registration, and login management. Password management deals with how users personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
>
>
TWiki user authentication is split into four categories: Password management, user mapping, user registration, and login management. Password management deals with how users' personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
 
Changed:
<
<
Once a user is logged on, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.
>
>
Once a user is logged in, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has cookies disabled). This avoids the need of having to log in again and again.
  TWiki user authentication is configured through the Security Settings pane in the configure interface.
Changed:
<
<
Please note FileAttachments are not protected by TWiki User Authentication.
>
>
Please note that FileAttachments are not protected by TWiki user authentication by default. The TWiki:TWiki.ApacheConfigGenerator has an option to protect file attachments.
  TIP Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.
Line: 37 to 37
 

User Mapping

Changed:
<
<
Often when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to TWiki, such as user groups.
>
>
Often, when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import into TWiki, such as user groups.
 
Changed:
<
<
By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.
>
>
By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support importing groups and other entities.
 

User Registration

Changed:
<
<
New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
>
>
New user registration uses the password manager to set and change passwords, and to store email addresses. It is also responsible for the new user verification process. The registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
 
Changed:
<
<
The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.
>
>
The registration process is also responsible for creating user topics and setting up the mapping information used by the User Mapping support.
  ALERT! Note: If you are restricting the entire Main web to TWikiGuest, you are required to add TWikiRegistrationAgent to ALLOWWEBCHANGE in your Main/WebPreferences. By doing so, new users are able to register without any errors.

Login Management

Changed:
<
<
Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.
>
>
Login management controls how users log in. There are three basic options: No login, login via a TWiki login page, and login using webserver authentication support.
 

No Login (select none in configure)

Changed:
<
<
Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.
>
>
No Login does exactly what it says. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity so you can't track individual user activity.
  ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.
Line: 71 to 71
 
  1. Use the configure interface to
    1. select the TWiki::LoginManager::TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
Changed:
<
<
    1. HELP there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent Browsers from remembering username and passwords if you are concerned about public terminal usage.
>
>
    1. HELP there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent browsers from remembering usernames and passwords if you are concerned about public terminal usage.
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Line: 91 to 91
  Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.
Changed:
<
<
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap or mod_auth_mysql you can just plug in directly to them.
>
>
The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules, such as mod_auth_ldap or mod_auth_mysql, you can just plug in directly to them.
  The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.
Line: 105 to 105
 You can use any other Apache authentication module that sets REMOTE_USER.
  1. Use configure to select the TWiki::LoginManager::ApacheLogin login manager.
  2. Use configure to set up TWiki to create the right kind of .htpasswd entries.
Changed:
<
<
  1. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
>
>
  1. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what needs to be done.
    HELP If you got it right, the browser should now ask for a login name and password when you click on Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
 
ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
  1. You can create a custom version of the TWikiRegistration form by copying the default topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
    The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user profile page by creating the Main.NewUserTemplate topic, which will then override the default.
Line: 118 to 118
 

Logons via bin/logon

Changed:
<
<
Any time a user requests a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" link as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.
>
>
Any time a user requests a page that needs authentication, they will be forced to log on. It may be convenient to have a "login" link as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log in.
  The bin/logon script enables this. If you are using Apache Login, the bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. Once authenticated, it will redirect the user to the view URL for the page from which the logon script was linked.
Line: 127 to 127
  TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.
Changed:
<
<
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
>
>
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers, it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
  There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
Line: 190 to 190
 

Controlling access to individual scripts

Changed:
<
<
You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for each of Template Login and Apache Login.
>
>
You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for Template Login and Apache Login.
 
  • For Template Login, update the {AuthScripts} list using configure
  • For Apache Login, add/remove the script from .htaccess

How to choose an authentication method

Changed:
<
<
One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. The TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.
>
>
One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.
  This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!
Line: 214 to 214
  If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".
Changed:
<
<
Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
>
>
Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the ether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.
  Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing: wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting

Revision 262011-06-05 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 82 to 82
  ALERT! At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.
Changed:
<
<
TIP You can create a custom version of the TWikiRegistration form by copying the topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
>
>
TIP You can create a custom version of the TWikiRegistration form by copying the topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
 
Changed:
<
<
TIP The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user home page by creating the Main.NewUserTemplate topic, which will then override the default.
>
>
TIP The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user profile page by creating the Main.NewUserTemplate topic, which will then override the default.
 

Apache Login (select TWiki::LoginManager::ApacheLogin in configure)

Line: 107 to 107
 
  1. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  2. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
Changed:
<
<
  1. You can create a custom version of the TWikiRegistration form by copying the default topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
    The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user home page by creating the Main.NewUserTemplate topic, which will then override the default.
>
>
  1. You can create a custom version of the TWikiRegistration form by copying the default topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user profile page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
    The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user profile page by creating the Main.NewUserTemplate topic, which will then override the default.
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Line: 127 to 127
  TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.
Changed:
<
<
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don;t enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
>
>
You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don't enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.
  There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
Line: 135 to 135
  You can get, set, and clear session variables from within TWiki web pages or by using script parameters. This allows you to use the session as a personal "persistent memory space" that is not lost until the web browser is closed. Also note that if a session variable has the same name as a TWiki preference, the session variables value takes precedence over the TWiki preference. This allows for per-session preferences.
Changed:
<
<
To make use of these features, use the tags:
>
>
To make use of these features, use the variables:
 
Changed:
<
<
%SESSION_VARIABLE{ "varName" }%
%SESSION_VARIABLE{ "varName" set="varValue" }%
%SESSION_VARIABLE{ "varName" clear="" }%

Note that you cannot override access controls preferences this way.

>
>
%SESSION_VARIABLE{ "varName" }% Read a session variable
%SESSION_VARIABLE{ "varName" set="varValue" }% Set a session variable
%SESSION_VARIABLE{ "varName" clear="" }% Clear a session variable

Special read-only session variables:

  • %SESSION_VARIABLE{"AUTHUSER"}% - user ID, current value:
  • %SESSION_VARIABLE{"SESSION_REQUEST_NUMBER"}% - number of pages accessed by current user since login, current value:

Notes:

  • You cannot override access controls preferences this way.
  • You can use the SetGetPlugin to set and get variables that are not user specific. This plugin can store variables persistently if needed.
 

Cookies and Transparent Session IDs

Line: 160 to 164
 
  • Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.
Changed:
<
<
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
>
>
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a user profile page in the Main web.
  TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.

NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %USERSWEB%.WikiUsername.
Changed:
<
<
This points WikiUsername to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
>
>
This points WikiUsername to the Main web, where user profile pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
 

Line: 223 to 227
 See TWiki:TWiki.SecuringTWikiSite for more information.
Changed:
<
<
Related Topics: AdminDocumentationCategory, TWikiAccessControl, TWiki:TWiki.TWikiUserAuthenticationSupplement, TWiki:TWiki.SecuringTWikiSite
>
>
Related Topics: AdminDocumentationCategory, TWikiAccessControl, VarAUTHREALM, VarGET, VarLOGIN, VarLOGOUT, VarSESSIONID, VarSESSIONVAR, VarSESSIONVARIABLE, VarSET, TWiki:TWiki.TWikiUserAuthenticationSupplement, TWiki:TWiki.SecuringTWikiSite
  -- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie, TWiki:Main.SvenDowideit

Revision 252007-04-19 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 30 to 30
 

Password Management

Changed:
<
<
As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the [[/twiki/bin/configure][configure] interface for more details.
>
>
As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.
  You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.
Line: 48 to 48
  The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.
Added:
>
>
ALERT! Note: If you are restricting the entire Main web to TWikiGuest, you are required to add TWikiRegistrationAgent to ALLOWWEBCHANGE in your Main/WebPreferences. By doing so, new users are able to register without any errors.
 

Login Management

Line: 61 to 63
 ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.

Changed:
<
<

Template Login (select TWiki::Client::TemplateLogin in configure)

>
>

Template Login (select TWiki::LoginManager::TemplateLogin in configure)

  Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users. Users can choose to have their session remembered so they will automatically be logged in the next time they start their browser.

Enabling Template Login

  1. Use the configure interface to
Changed:
<
<
    1. select the TWiki::Client::TemplateLogin login manager (on the Security Settings pane).
>
>
    1. select the TWiki::LoginManager::TemplateLogin login manager (on the Security Settings pane).
 
    1. select the appropriate password manager for your system, or provide your own.
Added:
>
>
    1. HELP there is also an EXPERT configure setting {TemplateLogin}{PreventBrowserRememberingPassword} that you can set to prevent Browsers from remembering username and passwords if you are concerned about public terminal usage.
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Line: 84 to 87
 TIP The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user home page by creating the Main.NewUserTemplate topic, which will then override the default.

Changed:
<
<

Apache Login (select TWiki::Client::ApacheLogin in configure)

>
>

Apache Login (select TWiki::LoginManager::ApacheLogin in configure)

  Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.
Line: 100 to 103
 

Enabling Apache Login using mod_auth

You can use any other Apache authentication module that sets REMOTE_USER.
Changed:
<
<
  1. Use configure to select the TWiki::Client::ApacheLogin login manager.
>
>
  1. Use configure to select the TWiki::LoginManager::ApacheLogin login manager.
 
  1. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  2. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
Line: 115 to 118
 

Logons via bin/logon

Changed:
<
<
Any time a user enters a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.
>
>
Any time a user requests a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" link as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.
 
Changed:
<
<
The bin/logon script accomplishes this. The bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon script was linked.
>
>
The bin/logon script enables this. If you are using Apache Login, the bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. Once authenticated, it will redirect the user to the view URL for the page from which the logon script was linked.
 

Sessions

Line: 222 to 225
  Related Topics: AdminDocumentationCategory, TWikiAccessControl, TWiki:TWiki.TWikiUserAuthenticationSupplement, TWiki:TWiki.SecuringTWikiSite
Changed:
<
<
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie
>
>
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie, TWiki:Main.SvenDowideit

Revision 242007-04-19 - TWikiContributor

Line: 1 to 1
Deleted:
<
<
 
Changed:
<
<

TWiki User Authentication

>
>

TWiki User Authentication

  TWiki site access control and user activity tracking options
Added:
>
>
 

Overview

Authentication, or "login", is the process by which a user lets TWiki know who they are.

Line: 26 to 27
  TIP Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.
Added:
>
>
 

Password Management

As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the [[/twiki/bin/configure][configure] interface for more details.

You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.

Added:
>
>
 

User Mapping

Often when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to TWiki, such as user groups.

By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.

Added:
>
>
 

User Registration

New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).

The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.

Added:
>
>
 

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.

Added:
>
>
 

No Login (select none in configure)

Changed:
<
<
Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.
>
>
Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.
 
Changed:
<
<
ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.
>
>
ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to administrators.
 
Added:
>
>
 

Template Login (select TWiki::Client::TemplateLogin in configure)

Changed:
<
<
Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users.
>
>
Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users. Users can choose to have their session remembered so they will automatically be logged in the next time they start their browser.
 

Enabling Template Login

  1. Use the configure interface to
Line: 65 to 72
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Changed:
<
<
  1. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
>
>
  1. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
 
ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.

TWikiAccessControl has more information on setting up access controls.

ALERT! At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.

Changed:
<
<
TIP You can create a custom version of the TWikiRegistration form by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
>
>
TIP You can create a custom version of the TWikiRegistration form by copying the topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
 
Changed:
<
<
TIP You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
>
>
TIP The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user home page by creating the Main.NewUserTemplate topic, which will then override the default.
 
Added:
>
>
 

Apache Login (select TWiki::Client::ApacheLogin in configure)

Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.

Line: 84 to 92
  The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.
Changed:
<
<
TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).
>
>
TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).
  The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.
Line: 96 to 104
 
  1. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  2. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
Changed:
<
<
  1. You can create a custom version of TWikiRegistration by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
    You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
>
>
  1. You can create a custom version of the TWikiRegistration form by copying the default topic, and then deleting or adding input tags in your copy. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly. Do not modify the version of TWikiRegistration shipped with TWiki, as your changes will be overwritten next time you upgrade.
    The default new user template page is in TWiki.NewUserTemplate. The same variables get expanded as in the template topics. You can create a custom new user home page by creating the Main.NewUserTemplate topic, which will then override the default.
 
  1. Register yourself in the TWikiRegistration topic.
    HELP Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
  2. Create a new topic to check if authentication works.
Changed:
<
<
  1. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
>
>
  1. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
 
ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls. TWikiAccessControl has more information on setting up access controls.
Line: 111 to 119
  The bin/logon script accomplishes this. The bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon script was linked.
Added:
>
>
 

Sessions

TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.

Line: 139 to 148
  For a number of reasons, it may not be possible to use cookies. In this case, TWiki has a fallback mechanism; it will automatically rewrite every internal URL it sees on pages being generated to one that also passes session information.
Added:
>
>
 

TWiki Username vs. Login Username

This section applies only if you are using authentication with existing login names (i.e. mapping from login names to WikiNames).

Line: 147 to 157
 
  • Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.
Changed:
<
<
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
>
>
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
  TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.

Changed:
<
<
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %MAINWEB%.WikiUsername. This points WikiUsername to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
>
>
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %USERSWEB%.WikiUsername. This points WikiUsername to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
 

Revision 232006-10-01 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 13 to 13
  TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.
Changed:
<
<
Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:
>
>
Quick Authentication Test - Use the %USERINFO% variable to return your current identity:
 
Changed:
<
<
TWiki user authentication is split into three sections; password management, user registration, and login management. Password management deals with how users are recognised (authenticated). Registration deals with how new users are added to the wiki. Login management deals with how users log in.
>
>
TWiki user authentication is split into four sections; password management, user mapping, user registration, and login management. Password management deals with how users personal data is stored. Registration deals with how new users are added to the wiki. Login management deals with how users log in.
 
Changed:
<
<
Once a user is logged on, they are remembered using a "session id" stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.
>
>
Once a user is logged on, they can be remembered using a Client Session stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.

TWiki user authentication is configured through the Security Settings pane in the configure interface.

  Please note FileAttachments are not protected by TWiki User Authentication.
Line: 26 to 28
 

Password Management

Changed:
<
<
As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.
>
>
As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the [[/twiki/bin/configure][configure] interface for more details.

You can easily plug in alternate password management modules to support interfaces to other third-party authentication databases.

User Mapping

 
Changed:
<
<

New User Registration

>
>
Often when you are using an external authentication method, you want to map from an unfriendly "login name" to a more friendly WikiName. Also, an external authentication database may well have user information you want to import to TWiki, such as user groups.
 
Changed:
<
<
New user registration uses the password manager to set and change passwords. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).
>
>
By default, TWiki supports mapping of usernames to wikinames, and supports TWiki groups internal to TWiki. If you want, you can plug in an alternate user mapping module to support import of groups etc.
 
Changed:
<
<
The registration process is responsible for creating user topics.
>
>

User Registration

New user registration uses the password manager to set and change passwords and store email addresses. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).

The registration process is also responsible for creating user topics, and setting up the mapping information used by the User Mapping support.

 

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.

Deleted:
<
<
You can select your chosen login through the Security Settings pane in the configure interface.
 

No Login (select none in configure)

Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.

Changed:
<
<
ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.
>
>
ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.
 

Template Login (select TWiki::Client::TemplateLogin in configure)

Changed:
<
<
Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out.
>
>
Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out. Client Sessions are used to remember users.
 

Enabling Template Login

Changed:
<
<
  1. Use the configure interface to
>
>
  1. Use the configure interface to
 
    1. select the TWiki::Client::TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
  1. Register yourself in the TWikiRegistration topic.
Line: 78 to 86
  TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).
Changed:
<
<
The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support. This allows the TWiki registration support to maintain usernames and passwords.
>
>
The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support.
  Warning: Do not use the Apache htpasswd program with .htpasswd files generated by TWiki! htpasswd wipes out email addresses that TWiki plants in the info fields of this file.
Line: 105 to 113
 

Sessions

Changed:
<
<
TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions using cookies. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address. See How to choose an authentication method for a discussion of the pros and cons of the various authentication methods.
>
>
TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address.

You don't have to enable sessions to support logins in TWiki. However it is strongly recommended. TWiki needs some way to remember the fact that you logged in from a particular browser, and it uses sessions to do this. If you don;t enable sessions, TWiki will try hard to remember you, but due to limitations in the browsers it may also forget you (and then suddenly remember you again later!). So for the best user experience, you should enable sessions.

  There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.
Line: 139 to 149
 
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
Changed:
<
<
TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.
>
>
TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.
 
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %MAINWEB%.WikiUsername.
Line: 164 to 174
 

Controlling access to individual scripts

You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for each of Template Login and Apache Login.
Changed:
<
<
  • For Template Login, update the {AuthScripts} list using configure
>
>
  • For Template Login, update the {AuthScripts} list using configure
 
  • For Apache Login, add/remove the script from .htaccess

How to choose an authentication method

Line: 173 to 183
  This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!
Changed:
<
<
Firstly, the most secure method is without doubt to use the webserver authentication support, with Sessions turned off.
>
>
At one extreme, the most secure method is to use TWiki via SSL (Secure Sockets Layer), with a login manager installed and Client Sessions turned off.
 
Changed:
<
<
The second most secure method is to use TWiki's internal authentication with Sessions turned off. This method is less secure than using the webserver because passwords are sent in plain text and can therefore be intercepted in transit.
>
>
Using TWiki with sessions turned off is a pain, though, as with all the login managers there are occasions where TWiki will forget who you are. The best user experience is achieved with sessions turned on.
  As soon as you allow the server to maintain information about a logged-in user, you open a door to potential attacks. There are a variety of ways a malicious user can pervert TWiki to obtain another users session ID, the most common of which is known as a cross-site scripting attack. Once a hacker has an SID they can pretend to be that user.

To help prevent these sorts of attacks, TWiki supports IP matching, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.

Deleted:
<
<
The third most secure method is to use sessions with IP matching ({UseIPMatching} switched on). Shorter session expiry times are more secure ({Sessions}{ExpireAfter}). The default session lifetime is 6 hours, which is quite a long lifetime for a session.
 Session IDs are usually stored by TWiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So TWiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in TWiki pages to include the session ID in the URL.

The first method works well as long as IP addresses are unique to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method.

Changed:
<
<
If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as the least secure method.
>
>
If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as "rather dodgy".

Most TWiki sites don't use SSL, so, as is the case with most sites that don't use SSL, there is always a possibility that a password could be picked out of the aether. Browsers do not encrypt passwords sent over non-SSL links, so using Apache Login is no more secure than Template Login.

Of the two shipped login managers, Apache Login is probably the most useful. It lets you do this sort of thing: wget --http-user=RogerRabbit --http-password=i'mnottelling http://www.example.com/bin/save/Sandbox/StuffAUTOINC0?text=hohoho,%20this%20is%20interesting i.e. pass in a user and password to a request from the command-line. However it doesn't let you log out.

Template Login degrades to url re-writing when you use a client like dillo that does not support cookies. However, you can log out and back in as a different user.

Finally, it would be really neat if someone was to work out how to use certificates to identify users.....

  See TWiki:TWiki.SecuringTWikiSite for more information.

Revision 222005-03-27 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

Line: 40 to 40
  You can select your chosen login through the Security Settings pane in the configure interface.
Changed:
<
<

No Login

>
>

No Login (select none in configure)

  Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.

ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.

Changed:
<
<

Template Login

>
>

Template Login (select TWiki::Client::TemplateLogin in configure)

  Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out.

Enabling Template Login

  1. Use the configure interface to
Changed:
<
<
    1. enable the TemplateLogin login manager (on the Security Settings pane).
>
>
    1. select the TWiki::Client::TemplateLogin login manager (on the Security Settings pane).
 
    1. select the appropriate password manager for your system, or provide your own.
  1. Register yourself in the TWikiRegistration topic.
Changed:
<
<

HELP Check that the password manager recongises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
>
>

HELP Check that the password manager recognises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
 
  1. Create a new topic to check if authentication works.
  2. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
    ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
Line: 68 to 68
  TIP You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
Changed:
<
<

Apache Login

>
>

Apache Login (select TWiki::Client::ApacheLogin in configure)

  Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.
Line: 80 to 80
  The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support. This allows the TWiki registration support to maintain usernames and passwords.
Added:
>
>
Warning: Do not use the Apache htpasswd program with .htpasswd files generated by TWiki! htpasswd wipes out email addresses that TWiki plants in the info fields of this file.
 

Enabling Apache Login using mod_auth

You can use any other Apache authentication module that sets REMOTE_USER.
Changed:
<
<
  1. Use configure to select the ApacheLogin login manager.
>
>
  1. Use configure to select the TWiki::Client::ApacheLogin login manager.
 
  1. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  2. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
Line: 119 to 121
 
Added:
>
>
Note that you cannot override access controls preferences this way.
 

Cookies and Transparent Session IDs

TWiki normally uses cookies to store session information on a client computer. Cookies are a common way to pass session information from client to server. TWiki cookies simply hold a unique session identifier that is used to look up a database of session information on the TWiki server.

Revision 202005-03-27 - TWikiContributor

Line: 1 to 1
 

TWiki User Authentication

TWiki site access control and user activity tracking options

Changed:
<
<
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).
>
>

Overview

 
Changed:
<
<
TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.
>
>
Authentication, or "login", is the process by which a user lets TWiki know who they are.
 
Changed:
<
<

Authentication Options

>
>
Authentication isn't just to do with access control. TWiki uses authentication to identify users, so it can keep track of who made changes, and manage a wide range of personal settings. With authentication enabled, users can personalise TWiki and contribute as recognised individuals, instead of shadows.
 
Changed:
<
<
No special installation steps are required if the server is already authenticated. If it isn't, you have these options for controlling user access:
  1. No login at all: Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
    • How: Default, no web server configuration necessary
  2. No login to view; require login to edit: Keeping track of who changed what and when, while keeping view access unrestricted is desirable in most TWiki deployments. This option is not suitable if you need TWikiAccessControl for view restricted content since TWiki does not know who a user is when looking at content.
    • How: Use Basic Authentication to control access by protecting key scripts: attach, edit, installpasswd, manage, preview, rename, save, upload. The TWikiInstallationGuide has step-by-step instructions.
  3. No login to view unless necessary; require login to edit: You prefer not to bother the user with login for unrestricted content, but you need TWikiAccessControl for view restricted content. There are two ways to accomplish this:
    • How 1: Use Basic Authentication with Partial Authentication (described below)
    • How 2: Use one of the Session TWiki:Plugins where you give the user the option to login and logout.
  4. Require login to view and edit: Most restrictive, but TWiki knows who the user is at all times. There are two ways to accomplish this:
    • How 1: Use Basic Authentication to authenticate the whole twiki/bin directory. Consult your web server documentation.
    • How 1: Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server. Consult your web server documentation.

Partial Authentication

Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:

  • Normally, the REMOTE_USER environment variable is set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
  • TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts, like view, will show the correct username instead of TWikiGuest.
  • Enable this feature by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default.
  • Copy the view script to viewauth (or better, create a symbolic link)
  • Add viewauth to the list of authenticated scripts in the twiki/bin/.htaccess file. The view script should not be listed in the .htaccess file.
  • ALERT! This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
>
>
TWiki authentication is very flexible, and can either stand alone or integrate with existing authentication schemes. You can set up TWiki to require authentication for every access, or only for changes. Authentication is also essential for access control.
  Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:
Deleted:
<
<
 
Added:
>
>
TWiki user authentication is split into three sections; password management, user registration, and login management. Password management deals with how users are recognised (authenticated). Registration deals with how new users are added to the wiki. Login management deals with how users log in.

Once a user is logged on, they are remembered using a "session id" stored in a cookie in the browser (or by other less elegant means if the user has disabled cookies). This avoids them having to log on again and again.

Please note FileAttachments are not protected by TWiki User Authentication.

TIP Tip: TWiki:TWiki.TWikiUserAuthenticationSupplement on TWiki.org has supplemental documentation on user authentication.

Password Management

As shipped, TWiki supports the Apache 'htpasswd' password manager. This manager supports the use of .htpasswd files on the server. These files can be unique to TWiki, or can be shared with other applications (such as an Apache webserver). A variety of password encodings are supported for flexibility when re-using existing files. See the descriptive comments in the Security Settings section of the configure interface for more details.

New User Registration

New user registration uses the password manager to set and change passwords. It is also responsible for the new user verification process. the registration process supports single user registration via the TWikiRegistration page, and bulk user registration via the BulkRegistration page (for admins only).

The registration process is responsible for creating user topics.

Login Management

Login management controls the way users have to log in. There are three basic options; no login, login via a TWiki login page, and login using the webserver authentication support.

You can select your chosen login through the Security Settings pane in the configure interface.

No Login

Does exactly what it says on the tin. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki style. All visitors are given the TWikiGuest default identity, so you can't track individual user activity.

ALERT! Note: This setup is not recommended on public websites for security reasons; anyone would be able to change system settings and perform tasks usually restricted to the TWikiAdminGroup.

Template Login

Template Login asks for a username and password in a web page, and processes them using whatever Password Manager you choose. Users can log in and log out.

Enabling Template Login

  1. Use the configure interface to
    1. enable the TemplateLogin login manager (on the Security Settings pane).
    2. select the appropriate password manager for your system, or provide your own.
  2. Register yourself in the TWikiRegistration topic.
    HELP Check that the password manager recongises the new user. If you are using .htpasswd files, check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you probably got a path wrong, or the permissions may not allow the webserver user to write to that file.
  3. Create a new topic to check if authentication works.
  4. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
    ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.

TWikiAccessControl has more information on setting up access controls.

ALERT! At this time TWikiAccessControls cannot control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up in the webserver to allow open access you may want to add .htaccess files in there to restrict access.

TIP You can create a custom version of the TWikiRegistration form by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.

TIP You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics

Apache Login

Using this method TWiki does not authenticate users internally. Instead it depends on the REMOTE_USER environment variable, which is set when you enable authentication in the webserver.

The advantage of this scheme is that if you have an existing website authentication scheme using Apache modules such as mod_auth_ldap or mod_auth_mysql you can just plug in directly to them.

The disadvantage is that because the user identity is cached in the browser, you can log in, but you can't log out again unless you restart the browser.

TWiki maps the REMOTE_USER that was used to log in to the webserver to a WikiName using the table in TWikiUsers. This table is updated whenever a user registers, so users can choose not to register (in which case their webserver login name is used for their signature) or register (in which case that login name is mapped to their WikiName).

The same private .htpasswd file used in TWiki Template Login can be used to authenticate Apache users, using the Apache Basic Authentication support. This allows the TWiki registration support to maintain usernames and passwords.

Enabling Apache Login using mod_auth

You can use any other Apache authentication module that sets REMOTE_USER.
  1. Use configure to select the ApacheLogin login manager.
  2. Use configure to set up TWiki to create the right kind of .htpasswd entries.
  3. Create a .htaccess file in the twiki/bin directory.
    HELP There is an template for this file in twiki/bin/.htaccess.txt that you can copy and change. The comments in the file explain what need to be done.
    HELP If you got it right, the browser should now ask for login name and password when you click on the Edit. If .htaccess does not have the desired effect, you may need to "AllowOverride All" for the directory in httpd.conf (if you have root access; otherwise, e-mail web server support)
    ALERT! At this time TWikiAccessControls do not control access to files in the pub area, unless they are only accessed through the viewfile script. If your pub directory is set up to allow open access you may want to add .htaccess files in there as well to restrict access
  4. You can create a custom version of TWikiRegistration by deleting or adding input tags. The name="" parameter of the input tags must start with: "Twk0..." (if this is an optional entry), or "Twk1..." (if this is a required entry). This ensures that the fields are carried over into the user home page correctly.
    You can customize the default user home page in NewUserTemplate. The same variables get expanded as in the template topics
  5. Register yourself in the TWikiRegistration topic.
    HELP Check that a new line with the username and encrypted password is added to the .htpasswd file. If not, you may have got a path wrong, or the permissions may not allow the webserver user to write to that file.
  6. Create a new topic to check if authentication works.
  7. Edit the TWikiAdminGroup topic in the Main web to include users with system administrator status.
    ALERT! This is a very important step, as users in this group can access all topics, independent of TWiki access controls.
TWikiAccessControl has more information on setting up access controls.

Logons via bin/logon

Any time a user enters a page that needs authentication, they will be forced to log on. It may be convenient to have a "logon" as well, to give the system a chance to identify the user and retrieve their personal settings. It may be convenient to force them to log on.

The bin/logon script accomplishes this. The bin/logon script must be setup in the bin/.htaccess file to be a script which requires a valid user. However, once authenticated, it will simply redirect the user to the view URL for the page from which the logon script was linked.

Sessions

TWiki uses the CPAN:CGI::Session and CPAN:CGI::Cookie modules to track sessions using cookies. These modules are de facto standards for session management among Perl programmers. If you can't use Cookies for any reason, CPAN:CGI::Session also supports session tracking using the client IP address. See How to choose an authentication method for a discussion of the pros and cons of the various authentication methods.

There are a number of TWikiVariables available that you can use to interrogate your current session. You can even add your own session variables to the TWiki cookie. Session variables are referred to as "sticky" variables.

Getting, Setting, and Clearing Session Variables

You can get, set, and clear session variables from within TWiki web pages or by using script parameters. This allows you to use the session as a personal "persistent memory space" that is not lost until the web browser is closed. Also note that if a session variable has the same name as a TWiki preference, the session variables value takes precedence over the TWiki preference. This allows for per-session preferences.

To make use of these features, use the tags:

%SESSION_VARIABLE{ "varName" }%
%SESSION_VARIABLE{ "varName" set="varValue" }%
%SESSION_VARIABLE{ "varName" clear="" }%

Cookies and Transparent Session IDs

TWiki normally uses cookies to store session information on a client computer. Cookies are a common way to pass session information from client to server. TWiki cookies simply hold a unique session identifier that is used to look up a database of session information on the TWiki server.

For a number of reasons, it may not be possible to use cookies. In this case, TWiki has a fallback mechanism; it will automatically rewrite every internal URL it sees on pages being generated to one that also passes session information.

 

TWiki Username vs. Login Username

Changed:
<
<
This section applies only if your TWiki site is installed on a server that is both authenticated and on an intranet.
>
>
This section applies only if you are using authentication with existing login names (i.e. mapping from login names to WikiNames).
 
Changed:
<
<
URCS internally manages two usernames: Login Username and TWiki Username.
>
>
URCS internally manages two usernames: Login Username and TWiki Username.
 
  • Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.

  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
Changed:
<
<
TWiki can automatically map an Intranet (Login) Username to a TWiki Username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.

  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work.
>
>
TWiki can automatically map an Intranet (Login) Username to a TWiki Username if the {AllowLoginName} is enabled in configure. The default is to use your WikiName as a login name.
 
Changed:
<
<
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
Main.WikiUsername or %MAINWEB%.WikiUsername
This points WikiUser to the URCS.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
>
>
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces, for example Main.WikiUsername or %MAINWEB%.WikiUsername. This points WikiUsername to the Main web, where user home pages are located, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
 

Changing Passwords

Changed:
<
<
Change and reset passwords using forms on regular pages. Use TWikiAccessControl to restrict use as required.
>
>
If your {PasswordManager} supports password changing, you can change and reset passwords using forms on regular pages.
 
Changed:
<
<
>
>
 
Changed:
<
<
No permission to view TWiki.ChangePassword
>
>

Changing E-mail Addresses

 
Changed:
<
<
>
>
If the active {PasswordManager} supports storage and retrieval of user e-mail addresses, you can change your e-mail using a regular page. As shipped, this is true only for the Apache 'htpasswd' password manager.
 
Changed:
<
<

Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

>
>
 
Changed:
<
<
-- TWiki:Main.MikeMannix - 19 May 2002
-- TWiki:Main.PeterThoeny - 25 Apr 2004
>
>

Controlling access to individual scripts

You may want to add or remove scripts from the list of scripts that require authentication. The method for doing this is different for each of Template Login and Apache Login.
  • For Template Login, update the {AuthScripts} list using configure
  • For Apache Login, add/remove the script from .htaccess

How to choose an authentication method

 
Changed:
<
<
>
>
One of the key features of TWiki is that it is possible to add HTML to topics. No authentication method is 100% secure on a website where end users can add HTML, as there is always a risk that a malicious user can add code to a topic that gathers user information, such as session IDs. The TWiki developers have been forced to make certain tradeoffs, in the pursuit of efficiency, that may be exploited by a hacker.

This section discusses some of the known risks. You can be sure that any potential hackers have read this section as well!

Firstly, the most secure method is without doubt to use the webserver authentication support, with Sessions turned off.

The second most secure method is to use TWiki's internal authentication with Sessions turned off. This method is less secure than using the webserver because passwords are sent in plain text and can therefore be intercepted in transit.

 
Added:
>
>
As soon as you allow the server to maintain information about a logged-in user, you open a door to potential attacks. There are a variety of ways a malicious user can pervert TWiki to obtain another users session ID, the most common of which is known as a cross-site scripting attack. Once a hacker has an SID they can pretend to be that user.
 
Added:
>
>
To help prevent these sorts of attacks, TWiki supports IP matching, which ensures that the IP address of the user requesting a specific session is the same as the IP address of the user who created the session. This works well as long as IP addresses are unique to each client, and as long as the IP address of the client can't be faked.

The third most secure method is to use sessions with IP matching ({UseIPMatching} switched on). Shorter session expiry times are more secure ({Sessions}{ExpireAfter}). The default session lifetime is 6 hours, which is quite a long lifetime for a session.

Session IDs are usually stored by TWiki in cookies, which are stored in the client browser. Cookies work well, but not all environments or users permit cookies to be stored in browsers. So TWiki also supports two other methods of determining the session ID. The first method uses the client IP address to determine the session ID. The second uses a rewriting method that rewrites local URLs in TWiki pages to include the session ID in the URL.

The first method works well as long as IP addresses are unique to each individual client, and client IP addresses can't be faked by a hacker. If IP addresses are unique and can't be faked, it is almost as secure as cookies + IP matching, so it ranks as the fourth most secure method.

If you have to turn IP matching off, and cookies can't be relied on, then you may have to rely on the second method, URL rewriting. This method exposes the session IDs very publicly, so should be regarded as the least secure method.

See TWiki:TWiki.SecuringTWikiSite for more information.

Related Topics: AdminDocumentationCategory, TWikiAccessControl, TWiki:TWiki.TWikiUserAuthenticationSupplement, TWiki:TWiki.SecuringTWikiSite

 
Changed:
<
<
META TOPICMOVED by="MikeMannix" date="999320061" from="TWiki.TWikiAuthentication" to="TWiki.TWikiUserAuthentication"
>
>
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.MikeMannix, TWiki:Main.CrawfordCurrie

Revision 192004-08-15 - PeterThoeny

Line: 1 to 1
 

TWiki User Authentication

Line: 15 to 15
 
  1. No login at all: Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
    • How: Default, no web server configuration necessary
  2. No login to view; require login to edit: Keeping track of who changed what and when, while keeping view access unrestricted is desirable in most TWiki deployments. This option is not suitable if you need TWikiAccessControl for view restricted content since TWiki does not know who a user is when looking at content.
Changed:
<
<
    • How: Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit, installpasswd, manage, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
>
>
    • How: Use Basic Authentication to control access by protecting key scripts: attach, edit, installpasswd, manage, preview, rename, save, upload. The TWikiInstallationGuide has step-by-step instructions.
 
  1. No login to view unless necessary; require login to edit: You prefer not to bother the user with login for unrestricted content, but you need TWikiAccessControl for view restricted content. There are two ways to accomplish this:
    • How 1: Use Basic Authentication with Partial Authentication (described below)
    • How 2: Use one of the Session TWiki:Plugins where you give the user the option to login and logout.
Line: 75 to 75
  Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

Changed:
<
<
-- MikeMannix - 19 May 2002
-- PeterThoeny - 25 Apr 2004
>
>
-- TWiki:Main.MikeMannix - 19 May 2002
-- TWiki:Main.PeterThoeny - 25 Apr 2004
 

Revision 182004-04-25 - PeterThoeny

Line: 1 to 1
 

TWiki User Authentication

Line: 50 to 50
  TWiki can automatically map an Intranet (Login) Username to a TWiki Username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.
Changed:
<
<
  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.
>
>
  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work.
 
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
Line: 75 to 75
  Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

Changed:
<
<
-- MikeMannix - 19 May 2002
>
>
-- MikeMannix - 19 May 2002
-- PeterThoeny - 25 Apr 2004
 

Revision 172003-05-29 - PeterThoeny

Line: 1 to 1
 

TWiki User Authentication

Line: 28 to 28
 Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:

  • Normally, the REMOTE_USER environment variable is set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
Deleted:
<
<
 
  • TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts, like view, will show the correct username instead of TWikiGuest.
Deleted:
<
<
 
  • Enable this feature by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default.
Changed:
<
<
>
>
  • Copy the view script to viewauth (or better, create a symbolic link)
  • Add viewauth to the list of authenticated scripts in the twiki/bin/.htaccess file. The view script should not be listed in the .htaccess file.
 
  • ALERT! This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.

Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:

Revision 162003-04-14 - PeterThoeny

Line: 1 to 1
 

TWiki User Authentication

Line: 11 to 11
 

Authentication Options

Changed:
<
<
No special installation steps are required if the server is already authenticated. If it isn't, you have three standard options for controlling user access:
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
>
>
No special installation steps are required if the server is already authenticated. If it isn't, you have these options for controlling user access:
  1. No login at all: Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
    • How: Default, no web server configuration necessary
  2. No login to view; require login to edit: Keeping track of who changed what and when, while keeping view access unrestricted is desirable in most TWiki deployments. This option is not suitable if you need TWikiAccessControl for view restricted content since TWiki does not know who a user is when looking at content.
    • How: Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit, installpasswd, manage, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
  3. No login to view unless necessary; require login to edit: You prefer not to bother the user with login for unrestricted content, but you need TWikiAccessControl for view restricted content. There are two ways to accomplish this:
    • How 1: Use Basic Authentication with Partial Authentication (described below)
    • How 2: Use one of the Session TWiki:Plugins where you give the user the option to login and logout.
  4. Require login to view and edit: Most restrictive, but TWiki knows who the user is at all times. There are two ways to accomplish this:
    • How 1: Use Basic Authentication to authenticate the whole twiki/bin directory. Consult your web server documentation.
    • How 1: Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server. Consult your web server documentation.
 

Partial Authentication

Revision 152002-12-29 - PeterThoeny

Line: 1 to 1
 

TWiki User Authentication

Line: 44 to 44
  TWiki can automatically map an Intranet (Login) Username to a TWiki Username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.
Changed:
<
<
  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.
>
>
  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.
 
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:

Revision 142002-05-19 - MikeMannix

Line: 1 to 1
 

TWiki User Authentication

Changed:
<
<
TWiki site access control and user activity tracking

Overview

>
>
TWiki site access control and user activity tracking options
  TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).
Line: 14 to 12
 

Authentication Options

No special installation steps are required if the server is already authenticated. If it isn't, you have three standard options for controlling user access:

Changed:
<
<
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
>
>
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
 

Partial Authentication

Line: 28 to 26
 
  • Enable this feature by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default.
Changed:
<
<
  • NOTE: This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
>
>
  • ALERT! This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
  Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:
Line: 36 to 34
 

TWiki Username vs. Login Username

Changed:
<
<
This section applies only if your URCS is installed on a server that is both authenticated and on an intranet.
>
>
This section applies only if your TWiki site is installed on a server that is both authenticated and on an intranet.

URCS internally manages two usernames: Login Username and TWiki Username.

 
Changed:
<
<
URCS internally manages two usernames: Login username and TWiki username.
>
>
  • Login Username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to TWiki by the REMOTE_USER environment variable, and used internally. Login Usernames are maintained by your system administrator.
 
Changed:
<
<
  • Login username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to URCS by the REMOTE_USER environment variable, and used by internally by URCS. Login usernames are maintained by your system administrator.
>
>
  • TWiki Username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
 
Changed:
<
<
  • TWiki username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.
>
>
TWiki can automatically map an Intranet (Login) Username to a TWiki Username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.
 
Changed:
<
<
URCS can automatically map an intranet username to a TWiki username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.
>
>
  • ALERT! In the original TWiki distribution, in twiki/data, there are two registration form topics, TWikiRegistration and TWikiRegistrationPub. The original form includes an intranet Login Username field. For Basic Authentication, the original form is replaced by the Pub version. If you started using TWiki on Basic Authentication and want to change, you have to switch back forms for future use, and manually correct the existing entries, by editing TWikiUsers, adding the Login Username for each member - PeterThoeny - pthoeny - 01 Jan 1999 - and also in the .htpasswd file, where you can either replace the WikiNames or duplicate the entries and have both, so both usernames will work. verification and clearer rewrite to follow in a bit. also link to original installation mention.
 
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
Line: 69 to 69
  Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

Added:
>
>
-- MikeMannix - 19 May 2002

 
Deleted:
<
<
-- MikeMannix - 29 Aug 2001
 
META TOPICMOVED by="MikeMannix" date="999320061" from="TWiki.TWikiAuthentication" to="TWiki.TWikiUserAuthentication"

Revision 132001-09-15 - MikeMannix

Line: 1 to 1
Deleted:
<
<
Warning: Can't find topic TWiki.UtilTempDocNote
 

TWiki User Authentication

Line: 9 to 7
 

Overview

Changed:
<
<
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).
>
>
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).
  TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.

Authentication Options

Changed:
<
<
No special installation steps need to be performed if the server is already authenticated. If not, you have three standard options for controlling user access:
>
>
No special installation steps are required if the server is already authenticated. If it isn't, you have three standard options for controlling user access:
 
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
Line: 61 to 59
 
Changed:
<
<
>
>
 
Warning
Can't INCLUDE TWiki.ChangePassword repeatedly, topic is already included.

Changed:
<
<
>
>
  Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

Revision 122001-09-14 - PeterThoeny

Line: 1 to 1
  Warning: Can't find topic TWiki.UtilTempDocNote

Line: 18 to 18
 No special installation steps need to be performed if the server is already authenticated. If not, you have three standard options for controlling user access:
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
Changed:
<
<
  1. Use Basic Authentication (HTAccess) to control access by protecting key scripts: attach, edit=, installpasswd, password, preview, rename, save, upload, view, viewfile using .htaccess files. The TWiki Installation Guide has step-by-step instructions.
>
>
  1. Use Basic Authentication (.htaccess) to control access by protecting key scripts: attach, edit=, installpasswd, preview, rename, save, upload using the .htaccess file. The TWikiInstallationGuide has step-by-step instructions.
 

Partial Authentication

Revision 102001-09-07 - MikeMannix

Line: 1 to 1
 
Changed:
<
<

TWiki User Authentication

>
>

TWiki User Authentication

  TWiki site access control and user activity tracking
Changed:
<
<

Overview

>
>

Overview

  TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).

TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.

Changed:
<
<

Authentication Options

>
>

Authentication Options

  No special installation steps need to be performed if the server is already authenticated. If not, you have three standard options for controlling user access:
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (HTAccess) to control access by protecting key scripts: attach, edit=, installpasswd, password, preview, rename, save, upload, view, viewfile using .htaccess files. The TWiki Installation Guide has step-by-step instructions.
Changed:
<
<

Partial Authentication

>
>

Partial Authentication

  Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:
Line: 34 to 34
 
Changed:
<
<

TWiki Username vs. Login Username

>
>

TWiki Username vs. Login Username

  This section applies only if your URCS is installed on a server that is both authenticated and on an intranet.
Line: 53 to 53
 

Changed:
<
<

Changing Passwords

>
>

Changing Passwords

  Change and reset passwords using forms on regular pages. Use TWikiAccessControl to restrict use as required.
Line: 70 to 70
 
Deleted:
<
<
-- PeterThoeny - 16 Mar 2001
 -- MikeMannix - 29 Aug 2001
Deleted:
<
<
 
META TOPICMOVED by="MikeMannix" date="999320061" from="TWiki.TWikiAuthentication" to="TWiki.TWikiUserAuthentication"

Revision 92001-09-06 - MikeMannix

Line: 1 to 1
 

TWiki User Authentication

Line: 13 to 13
 

Authentication Options

Changed:
<
<
No special installation steps need to be performed if the server is already authenticated. If not, you have three remaining options to controlling user access:
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public - anyone can browse and edit freely, in classic Wiki mode.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. The TWiki Installation Guide has step-by-step instructions.
  3. Use SSL to authenticate and secure the whole server.
>
>
No special installation steps need to be performed if the server is already authenticated. If not, you have three standard options for controlling user access:
  1. Forget about authentication to make your site completely public - anyone can browse and edit freely, in classic Wiki mode. All visitors are assigned the TWikiGuest default identity, so you can't track individual user activity.
  2. Use SSL (Secure Sockets Layer; HTTPS) to authenticate and secure the whole server.
  3. Use Basic Authentication (HTAccess) to control access by protecting key scripts: attach, edit=, installpasswd, password, preview, rename, save, upload, view, viewfile using .htaccess files. The TWiki Installation Guide has step-by-step instructions.
 
Changed:
<
<

Tracking by IP Address

>
>

Partial Authentication

 
Changed:
<
<
The REMOTE_USER environment variable is only set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
>
>
Tracking by IP address is an experimental feature, enabled in lib/TWiki.cfg. It lets you combine open access to some functions, with authentication on others, with full user activity tracking:
 
Changed:
<
<
There is a way to tell TWiki to remember the user for the scripts that are not authenticated, ex: in case the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address/username pairs in the file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
>
>
  • Normally, the REMOTE_USER environment variable is set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
 
Changed:
<
<
Authentication Test: You are TWikiGuest (%WIKIUSERNAME%)
>
>
  • TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts, like view, will show the correct username instead of TWikiGuest.

  • Enable this feature by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki then persistently stores the IP address/username pairs in the file, $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default.

  • NOTE: This approach can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.

Quick Authentication Test - Use the %WIKIUSERNAME% variable to return your current identity:

 

TWiki Username vs. Login Username

Line: 33 to 41
 URCS internally manages two usernames: Login username and TWiki username.

  • Login username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to URCS by the REMOTE_USER environment variable, and used by internally by URCS. Login usernames are maintained by your system administrator.
Added:
>
>
 
  • TWiki username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.

URCS can automatically map an intranet username to a TWiki username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.

Changed:
<
<
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
>
>
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
 
Main.WikiUsername or %MAINWEB%.WikiUsername
This points WikiUser to the URCS.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
Line: 46 to 55
 

Changing Passwords

Changed:
<
<
Change and reset passwords using forms on regular pages. Use topic-level TWikiAccessControl to restrict use as required.
>
>
Change and reset passwords using forms on regular pages. Use TWikiAccessControl to restrict use as required.
 
Changed:
<
<
>
>
 
Warning
Can't INCLUDE TWiki.ChangePassword repeatedly, topic is already included.
Changed:
<
<
>
>
 

Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu

Revision 82001-09-06 - MikeMannix

Line: 1 to 1
 

TWiki User Authentication

Changed:
<
<
Controlling TWiki site access and logging authorized user activity
>
>
TWiki site access control and user activity tracking
 

Overview

Line: 14 to 14
 

Authentication Options

No special installation steps need to be performed if the server is already authenticated. If not, you have three remaining options to controlling user access:

Changed:
<
<
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public - anyone can browse and edit freely, in classic Wiki mode.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. The TWiki Installation Guide has step-by-step instructions.
  3. Use SSL to authenticate and secure the whole server.
>
>
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public - anyone can browse and edit freely, in classic Wiki mode.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. The TWiki Installation Guide has step-by-step instructions.
  3. Use SSL to authenticate and secure the whole server.
 

Tracking by IP Address

Line: 43 to 43
 This points WikiUser to the URCS.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
Added:
>
>
 

Changing Passwords

Added:
>
>
Change and reset passwords using forms on regular pages. Use topic-level TWikiAccessControl to restrict use as required.

 
Warning
Can't INCLUDE TWiki.ChangePassword repeatedly, topic is already included.
Added:
>
>
 
Added:
>
>

  Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu
Added:
>
>
  -- PeterThoeny - 16 Mar 2001
-- MikeMannix - 29 Aug 2001

Revision 72001-09-04 - MikeMannix

Line: 1 to 1
 

TWiki User Authentication

Line: 45 to 45
 

Changing Passwords

Changed:
<
<
Warning: Can't find topic TWiki.ChangingPasswords
>
>
Warning
Can't INCLUDE TWiki.ChangePassword repeatedly, topic is already included.

Remember your password? Use ChangePassword instead. Otherwise, use this form to get a new one e-mailed to you.

After submitting this form, you will receive an e-mail with your new, system-generated password, and a link to a page where you can change it.
<-- 
  • Set NOTMODIFYABLE =
-->

ALERT! you must have at least one valid registered e-mail to be able to reset your password. If none of your registered e-mail addresses is valid, and you have forgotten your password, contact webmaster@cs.rochester.edu.

Fields marked ** are required
Your LoginName: **
 
<-- /twikiFormStep-->
<-- /twikiFormSteps-->

Info UserList has a list of other TWiki users
Info If you have any questions, please contact webmaster@cs.rochester.edu
  -- PeterThoeny - 16 Mar 2001
-- MikeMannix - 29 Aug 2001

Revision 52001-09-02 - MikeMannix

Line: 1 to 1
 

TWiki User Authentication

Changed:
<
<
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol).
>
>
Controlling TWiki site access and logging authorized user activity

Overview

TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable Basic Authentication (.htaccess) or SSL "secure server" authentication (https protocol).

  TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.

Authentication Options

No special installation steps need to be performed if the server is already authenticated. If not, you have three remaining options to controlling user access:

Changed:
<
<
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. TWiki Installation Notes has more.
>
>
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public - anyone can browse and edit freely, in classic Wiki mode.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. The TWiki Installation Guide has step-by-step instructions.
 
  1. Use SSL to authenticate and secure the whole server.

Tracking by IP Address

The REMOTE_USER environment variable is only set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.

Changed:
<
<
There is a way to tell TWiki to remember the user for the scripts that are not authenticated, ex: in case the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
>
>
There is a way to tell TWiki to remember the user for the scripts that are not authenticated, ex: in case the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address/username pairs in the file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.
  Authentication Test: You are TWikiGuest (%WIKIUSERNAME%)
Line: 34 to 38
 URCS can automatically map an intranet username to a TWiki username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.

Changed:
<
<
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
>
>
NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
 
Main.WikiUsername or %MAINWEB%.WikiUsername
This points WikiUser to the URCS.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.

Revision 42001-09-01 - MikeMannix

Line: 1 to 1
 
Changed:
<
<

TWiki Authentication

>
>

TWiki User Authentication

  TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol).
Line: 41 to 41
  -- PeterThoeny - 16 Mar 2001
-- MikeMannix - 29 Aug 2001
Added:
>
>
META TOPICMOVED by="MikeMannix" date="999320061" from="TWiki.TWikiAuthentication" to="TWiki.TWikiUserAuthentication"

Revision 32001-08-29 - MikeMannix

Line: 1 to 1
Added:
>
>
 

TWiki Authentication

Changed:
<
<
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol)
>
>
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol).
 
Changed:
<
<
TWiki keeps track who made changes to topics at what time. This gives a complete audit trail of changes.
>
>
TWiki uses visitor identification to keep track of who made changes to topics at what time and to manage a wide range of personal site settings. This gives a complete audit trail of changes and activity.
 
Changed:
<
<
No special installation steps need to be performed in case the server is already autenticated. If not you can opt for one of these:
  • Forget about authentication. All changes will be registered as TWikiGuest user, e.g. you can't tell who made changes.
  • Use basic authentication for the edit and attach scripts. TWiki Installation Notes tells you more about that.
  • Use SSL to authenticate and secure the whole server.
>
>

Authentication Options

 
Changed:
<
<
The REMOTE_USER environment variable is only set for the scripts that are under authentication. If for example the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
>
>
No special installation steps need to be performed if the server is already authenticated. If not, you have three remaining options to controlling user access:
  1. Forget about authentication. All changes are registered to TWikiGuest user, so you can't tell who made changes. Your site is completely open and public.
  2. Use Basic Authentication for the edit and attach scripts. This uses .htaccess and generates the familiar grey log-in window. TWiki Installation Notes has more.
  3. Use SSL to authenticate and secure the whole server.
 
Changed:
<
<
There is a way to tell TWiki to remember the user for the scripts that are not authenticated, e.g. for the case where the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address / username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail in case the IP address changes due to dynamically assigned IP addresses or proxy servers.
>
>

Tracking by IP Address

 
Changed:
<
<
Test: You are TWikiGuest.
>
>
The REMOTE_USER environment variable is only set for the scripts that are under authentication. If, for example, the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.

There is a way to tell TWiki to remember the user for the scripts that are not authenticated, ex: in case the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address/username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non-authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail if the IP address changes due to dynamically assigned IP addresses or proxy servers.

Authentication Test: You are TWikiGuest (%WIKIUSERNAME%)

TWiki Username vs. Login Username

This section applies only if your URCS is installed on a server that is both authenticated and on an intranet.

URCS internally manages two usernames: Login username and TWiki username.

  • Login username: When you login to the intranet, you use your existing login username, ex: pthoeny. This name is normally passed to URCS by the REMOTE_USER environment variable, and used by internally by URCS. Login usernames are maintained by your system administrator.
  • TWiki username: Your name in WikiNotation, ex: PeterThoeny, is recorded when you register using TWikiRegistration; doing so also generates a personal home page in the Main web.

URCS can automatically map an intranet username to a TWiki username, provided that the username pair exists in the TWikiUsers topic. This is also handled automatically when you register.

NOTE: To correctly enter a WikiName - your own or someone else's - be sure to include the Main web name in front of the Wiki username, followed by a period, and no spaces. Ex:
Main.WikiUsername or %MAINWEB%.WikiUsername
This points WikiUser to the URCS.Main web, where user registration pages are stored, no matter which web it's entered in. Without the web prefix, the name appears as a NewTopic everywhere but in the Main web.
  -- PeterThoeny - 16 Mar 2001
Added:
>
>
-- MikeMannix - 29 Aug 2001

Revision 22001-03-16 - PeterThoeny

Line: 1 to 1
Changed:
<
<
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol)
>
>

TWiki Authentication

TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol)

  TWiki keeps track who made changes to topics at what time. This gives a complete audit trail of changes.

No special installation steps need to be performed in case the server is already autenticated. If not you can opt for one of these:

  • Forget about authentication. All changes will be registered as TWikiGuest user, e.g. you can't tell who made changes.
Changed:
<
<
  • Use basic authentication for the edit and attach scripts. TWiki Installation tells you more about that.
>
>
 
  • Use SSL to authenticate and secure the whole server.
Changed:
<
<
The REMOTE_USER environment variable is only set for the scripts that are under authentication. If for example the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.
>
>
The REMOTE_USER environment variable is only set for the scripts that are under authentication. If for example the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.

There is a way to tell TWiki to remember the user for the scripts that are not authenticated, e.g. for the case where the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address / username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in TWiki.cfg. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail in case the IP address changes due to dynamically assigned IP addresses or proxy servers.

 
Changed:
<
<
There is a way to tell TWiki to remember the user for the scripts that are not authenticated, e.g. for the case where the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address / username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in wikicfg.pm. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail in case the IP address changes due to dynamically assigned IP addresses or proxy servers. Test: You are TWikiGuest.
>
>
Test: You are TWikiGuest.
 
Changed:
<
<
-- PeterThoeny - 02 Nov 2000
>
>
-- PeterThoeny - 16 Mar 2001

Revision 12000-11-02 - PeterThoeny

Line: 1 to 1
Added:
>
>
TWiki does not authenticate users internally, it depends on the REMOTE_USER environment variable. This variable is set when you enable basic authentication or authentication via SSL (https protocol)

TWiki keeps track who made changes to topics at what time. This gives a complete audit trail of changes.

No special installation steps need to be performed in case the server is already autenticated. If not you can opt for one of these:

  • Forget about authentication. All changes will be registered as TWikiGuest user, e.g. you can't tell who made changes.
  • Use basic authentication for the edit and attach scripts. TWiki Installation tells you more about that.
  • Use SSL to authenticate and secure the whole server.

The REMOTE_USER environment variable is only set for the scripts that are under authentication. If for example the edit, save and preview scripts are authenticated, but not view, you would get your WikiName in preview for the %WIKIUSERNAME% variable, but view will show TWikiGuest instead of your WikiName.

There is a way to tell TWiki to remember the user for the scripts that are not authenticated, e.g. for the case where the REMOTE_USER environment variable is not set. TWiki can be configured to remember the IP address / username pair whenever an authentication happens (edit topic, attach file). Once remembered, the non authenticated scripts like view will show the correct username instead of TWikiGuest. You can enable this by setting the $doRememberRemoteUser flag in wikicfg.pm. TWiki persistently stores the IP address / username pairs in file $remoteUserFilename, which is "$dataDir/remoteusers.txt" by default. Please note that this can fail in case the IP address changes due to dynamically assigned IP addresses or proxy servers. Test: You are TWikiGuest.

-- PeterThoeny - 02 Nov 2000

 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.TWikiUserAuthentication.