Trac sessions are authenticated per request based on browser cookies. Therefor a number of options control some critical browser cookie properties.
Determines how long the browser will cache authentication information, and therefore, after how much inactivity a user will have to log in again. Default (0 s) makes cookie expire at browsing sessions end.
Required if this Trac instance is only accessible through HTTPS.
Potentially troublesome for users with dynamic IP adress, but disregarded for persistant sessions.
You can still manage some password stores with AccountManagerPlugin, if you configure them in the next section.
AccountManagerPlugin provides a form-based login page, even integrating links to related actions:
accompanied by its own, custom version of LoginModule.
If you enable this feature, you'll want to review and adjust some Trac options related to session authentication. Note, that AccountManagerPlugin's LoginModule changes the default value for auth_cookie_lifetime to 30 days.
This is, user checks a "Remember Me" checkbox in the AccountManagerPlugin login form and, next time he visits the site within 30 days, he'll be remembered and authenticated automatically.
Driving a refresh process to decrease vulnerability of long-lasting sessions. Zero equals to never.
Set this to a common base path of several Trac instances to share the cookie, providing cheap Single-Sign-On experience. This enables AccountManagerPlugin's authentication data distribution to Trac instances with matching cookie path.
AccountManagerPlugin manages user credentials in a modular back-end providing access to at least one password store. While store chaining works flawlessly, this advanced configuration scenario is not supported by the configuration wizard yet.
AccountManagerPlugin's SessionStore implements password storage in db table 'session_attributes'. Its the default choice mainly for avoiding additional dependencies like directory and file permissions. While great to resolve some concurrent access issues too, this password store has some shortcomings as well. Notably it does not support seamless hash type migration yet, and its no candidate for shared use by multiple Trac instances or even by applications beyond Trac.
AccountManagerPlugin includes native support for common Apache file formats 'htpasswd' and 'htdigest'. Note that setting appropriate directory and file permissions is cruicial for this password store, but not covered by this configuration wizard.
HtDigestStore
HtPasswdStore
SvnServePasswordStore includes support for reading svnserve's password file format. This is another way to enable shared use of authentication data, but relies on independed management of the password file.
Path to the users file, leave blank to locate the users file by reading svnserve.conf
AccountManagerPlugin enables use of standard HTTP authentication by its HttpAuthStore component. Both Basic and Digest authentication callenges are supported. Apart from being read-only this password store does even not support listing users for obvious reasons.
URL of the HTTP authentication service
AccountManagerPlugin's modular password store concept encourages creation of even more ways to provide user credential beyond the natively supported stores. Setup assistance for these 3rd-party authentication providers is not implemented yet.
Select the desired password stores and related options to enable concurrent use of multiple password stores. Order matters. This is merely a placeholder to skip further configuration details in this section if checked, or if a multi-store setup is detected in current configuration.
Ordered list of password stores, queried in turn
While AccountManagerPlugin does not enforce password rules in general, there are some other ways to alter password handling.
Enable the password reset procedure, that relies on a working email sender for Trac, supporting both TracAnnouncer and TracNotification
Length of the randomly-generated passwords created when resetting the password for an account
Force the user to change password after a successful reset
You may require administrative approval of new accounts for the user registration process. The ability to immediately ban existing accounts is another, related but independed feature.
Ordered list of checks to use for validating registration requests
All checks provided by AccountManagerPlugin are enabled per default, but some are configurable on their own, and checks like BotTrapCheck don't work at all without additional configuration
Whether account registration requires administrative approval to enable the account or not
Enable the email verification procedure, that relies on a working email sender for Trac, supporting both TracAnnouncer and TracNotification
AccountGuard component provides additional protection. It is an add-on to AccountManagerPlugin's own LoginModule discouraging brute-force login attempts.
Save the configuration and create one admin and one regular user account.