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 md5 password encoding.
You may need to change it if you are sharing a password file with another
application.
{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
Minimum length for a password, for new
registrations and password changes. If you want to allow null passwords,
set this to 0.
{MinPasswordLength}
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
User Mapping
This allows advanced users to write and
over-ride the TWiki User and group mappings rather than the
loginname->TWikiUser and Groups definitions comming from TWiki user and
group topics. Currently only TWikiUserMapping is implemented.
TWiki::Users::TWikiUserMapping - uses TWiki user and group topics to
determine user information and group memberships
{UserMappingManager}
TWiki::Users::TWikiUserMapping
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}