Sessions
You can use persistent CGI session tracking even if you are not using
login. This allows you to have persistent session variables - for
example, skins. Client sessions are not required for logins to work,
but TWiki will not be able to remember users unless there is some other
mechanism - such as browser cacheing of authentication - available. #
See TWiki.TWikiUserAuthentication for a full discussion of the pros and
cons of using persistent sessions.
{UseClientSessions}
Absolute file path of the directory in which session files are stored. Defaults to /tmp. Security Note: The directory must not be browseable from the web, otherwise it could be used to mount an attack on the server!
{Sessions}{Dir}
EXPERT Set the session timeout, in
seconds. The session will be cleared after this amount of time without
the session being accessed. The default is 6 hours (21600 seconds). Note By
default, session expiry is done "on the fly" by the same processes used
to serve TWiki requests. As such it imposes a load on the server. When
there are very large numbers of session files, this load can become
significant. For best performance, you can set {Sessions}{ExpireAfter}
to a negative number, which will mean that TWiki won't try to clean up
expired sessions using CGI processes. Instead you should use a cron job
to clean up expired sessions. The standard maintenance cron script tools/tick_twiki.pl includes this function.
{Sessions}{ExpireAfter}
EXPERT If you have persistent sessions
enabled, then TWiki will use a cookie in the browser to store the
session ID. If the client has cookies disabled, then TWiki will not be
able to record the session. As a fallback, TWiki can rewrite local URLs
to pass the session ID as a parameter to the URL. This is a potential
security risk, because it increases the chance of a session ID being
stolen (accidentally or intentionally) by another user. If this is
turned off, users with cookies disabled will have to re-authenticate
for every secure page access (unless you are using
{Sessions}{MapIP2SID}).
{Sessions}{IDsInURLs}
EXPERT It's important to check that the
user trying to use a session is the same user who originally created
the session. TWiki does this by making sure, before initializing a
previously stored session, that the IP address stored in the session
matches the IP address of the user asking for that session. Turn this
off if a client IP address may change during the lifetime of a session
(unlikely)
{Sessions}{UseIPMatching}
EXPERT For compatibility with older
versions, TWiki supports the mapping of the clients IP address to a
session ID. You can only use this if all client IP addresses are known
to be unique. If this option is enabled, TWiki will not store
cookies in the browser. The mapping is held in the file
$cfg{Sessions}{Dir}/ip2sid. If you turn this option on, you can safely
turn {Sessions}{IDsInURLs} off .
{Sessions}{MapIP2SID} Authentication
TWiki supports different ways of responding when the user asks to log
in (or is asked to log in as the result of an access control fault).
They are: none - Don't support logging in, all users have access to everything.
TWiki::Client::TemplateLogin - Redirect to the login template, which
asks for a username and password in a form. Does not cache the ID in
the browser, so requires client sessions to work.
TWiki::Client::ApacheLogin - Redirect to an '...auth' script for which
Apache can be configured to ask for authorization information. Does not
require client sessions, but works best with them enabled.
{LoginManager} TWiki::Client::TemplateLogin none TWiki::Client::ApacheLogin
Guest user's login name (guest)
{DefaultUserLogin}
Guest user's wiki name (TWikiGuest)
{DefaultUserWikiName}
An admin user login is is required by the install script for some
addons and plugins, usually to gain write access to the TWiki web.
(TWikiAdminGroup)
{AdminUserWikiName}
EXPERT Group of users that can use
special action=repRev and action=delRev on =save= and ALWAYS have edit
powers. See TWiki.TWikiDocumentation for an explanation of twiki
groups. This user will also run all the standard cron jobs, such as
statistics and mail notification. Make sure you edit this topic if you enable authentication
{SuperAdminGroup}
EXPERT Name of topic in the
{UsersWebName} web where registered users are listed. Automatically
maintained by the standard registration scripts. If you change this setting you will have to use TWiki to manually rename the existing topic
{UsersTopicName}
EXPERT Map login name to Wiki name via
the mapping in the topic named in {UsersTopicName}. Set this to $FALSE
for .htpasswd authenticated sites where the user's wiki name is the
name they use to log in, or if you have some other way of making the
mapping to a Wiki name (e.g. a local Plugin).
{MapUserToWikiName}
EXPERT Comma-separated list of scripts
that require the user to authenticate. With TemplateLogin, any time an
unauthenticated user attempts to access one of these scripts, they will
be redirected to the login script. With ApacheLogin, they will be
redirected to the logon script (note login and logon; they are
different scripts). This approach means that only the logon script
needs to be specified as require valid-user when using Apache
authentication. If you want finer access control (e.g. authorised
users only in one web but open access in another) then you should
*clear* this list, and use TWiki Permissions to control access. Users
wishing to make changes will have to log in by clicking a "log in" link
instead of being automatically redirected when they try to edit.
{AuthScripts}
EXPERT Authentication realm. This is normally only used in the login prompt screen by the TWiki::Client::TemplateLogin manager.
{AuthRealm} Passwords
Name of the password handler implementation. The password handler
manages the passwords database, and provides password lookup, and
optionally password change, services. TWiki ships with two alternative
implementations: TWiki::Users::HtPasswdUser - handles 'htpasswd' format files, with passwords encoded as per the HtpasswdEncoding
TWiki::Users::ApacheHtpasswdUser - should behave identically to
HtpasswdUser, but uses the CPAN:Apache::Htpasswd package to interact
with Apache. It is shipped mainly as a demonstration of how to write a
new password manager. You can provide your own alternative
by implementing a new subclass of TWiki::Users::Password, and pointing
{PasswordManager} at it in lib/LocalSite.cfg. If 'none' is selected,
users will not be able to change passwords, and will always be
authenticated by the TemplateLogin manager, regardless of what username
or password they enter. This may be useful when you want to enable
logins so TWiki can identify contributors, but you don't care about
passwords.
{PasswordManager} TWiki::Users::HtPasswdUser none TWiki::Users::ApacheHtpasswdUser
Path to the file that stores passwords, for the TWiki::Users::HtPasswdUser password manager. You can use the htpasswd Apache program to create a new password file with the right encoding.
{Htpasswd}{FileName}
Password encryption, for the TWiki::Users::HtPasswdUser password manager. You can use the htpasswd Apache program to create a new password file with the right encoding. crypt is the default, and should be used on Linux/Unix. sha1 is recommended for use on Windows. md5
may be useful on sites where password files are required to be
portable. In this case, the {AuthRealm} is used with the username and
password to generate the encrypted form of the password, thus: user:{AuthRealm}:password .
Take note of this, because it means that if the {AuthRealm} changes,
any existing MD5 encoded passwords will be invalidated by the change! plain stores passwords as plain text (no encryption).
{Htpasswd}{Encoding} crypt sha1 md5 plain Registration
If you want users to be able to use a login ID other than their
wikiname, you need to turn this on. It controls whether the 'LoginName'
box appears during the user registration process. If you are using
intranet authentication instead of TWiki authentication, you probably
need to turn this on.
{Register}{AllowLoginName}
EXPERT Hide password in registration email to the *user* Note that TWiki sends admins a separate confirmation.
{Register}{HidePasswd}
EXPERT Whether registrations must be verified by the user following a link sent in an email to the user's registered email address
{Register}{NeedVerification} Paths
EXPERT Path control. If set, overrides
the default PATH setting to control where TWiki looks for programs.
Check notes for your operating system. NOTE: it is better to use full
pathnames in the paths to external programs, rather than relying on
this path. Unix or Linux path separator is : ensure diff and shell (Bourne or bash type) is found on the path. Windows ActiveState Perl, with non-Cygwin RCS, OR no PERL5SHELL setting. path separator is ; The Windows system directory (e.g. c:\winnt\system32) is required in this path. Must NOT use '/' in pathnames as this upsets cmd.exe - single '' is OK using Perl single-quoted string. Windows: ActiveState Perl, with Cygwin RCS and PERL5SHELL set to 'c:/cygwin/bin/bash.exe -c' path separator is ;
best to avoid 'c:/foo' type paths, because it can cause a Perl
'Insecure directory in $ENV{PATH}' error. The best approach is to
convert 'c:/foo' to '/cygdrive/c/foo' - odd looking but it works! The
Windows system directory (e.g. /cygdrive/c/winnt/system32) is required
in this path. For example:
/cygdrive/c/YOURCYGWINDIR/bin;/cygdrive/c/YOURWINDOWSDIR/system32 Windows: ActiveState Perl, with non-Cygwin RCS, OR no PERL5SHELL setting. path separator is ';'
The Windows system directory is required in this path. Must NOT use /
in directories on the path as this upsets cmd.exe - single '\' is OK
using Perl single quoted string.
{SafeEnvPath} Miscellaneous
EXPERT Remove .. from %INCLUDE{filename}%, to stop includes of relative paths.
{DenyDotDotInclude}
EXPERT Allow %INCLUDE of URLs. This is
disabled by default, because it is possible to mount a
denial-of-service (DoS) attack on a TWiki site using INCLUDE and URLs.
Only enable it if you are in an environment where a DoS attack is not a
high risk.
{INCLUDE}{AllowURLs}
EXPERT Allow the use of SCRIPT tags in
content. if this is set false, all SCRIPT sections will be removed from
the body of topics. They can still be used in the HEAD section, though.
Note that this may prevent some plugins from functioning correctly.
{AllowInlineScript}
EXPERT Filter-in regex for uploaded
(attached) file names (Matching filenames will have .txt appended)
WARNING: Be sure to update this list with any configuration or script
filetypes that are automatically run by your web server
{UploadFilter}
EXPERT Filter-in regex for webnames, topic names, usernames, include paths and skin names
{NameFilter}
EXPERT If this is set, the the search module will use more relaxed rules governing regular expressions searches.
{ForceUnsafeRegexes}
EXPERT Build the path to /twiki/bin
from the URL that was used to get this far. This can be useful when
rewriting rules or redirection are used to shorten URLs. Note that
displayed links are incorrect after failed authentication if this is
set, so unless you really know what you are doing, leave it alone.
{GetScriptUrlFromCgi}
EXPERT Remove port number from URL. If
set, and a URL is given with a port number e.g.
http://my.server.com:8080/twiki/bin/view, this will strip off the port
number before using the url in links.
{RemovePortNumber}