Settings reference

Since RestAuth is implemented as a Django project, RestAuth not only uses all settings available in Django, but also features a few additional settings that ease administration and configure RestAuth. This document is a complete reference of settings that are either specific to RestAuth or are normal Django settings that RestAuth handles in a different way.

CACHES

Default: {}

This setting is available in Django. Please see the official documentation on how to use this setting.

RestAuth automatically adjusts MIDDLEWARE_CLASSES (as documented here) if you configure any caches.

ENABLE_SESSIONS

Default: False

The RestAuth protocol by default does not use HTTP sessions, since every request is authenticated using HTTP Basic Authentication. Sessions are thus disabled in RestAuth, because they come with a considerable performance penalty.

If a client still uses HTTP sessions, you can set this configuarion variable to True. This has the effect of adding the appropriate middleware classes to MIDDLEWARE_CLASSES.

HASH_ALGORITHM

Default: sha512

The HASH_ALGORITHM setting configures which algorithm is used for hashing new passwords. If you set this to a new algorithm, old password hashes will be updated whenever a user logs in. RestAuth supports all algorithms supported by the hashlib module.

RestAuth also supports reading and storing hashes the same way that legacy systems store them. Reading such hashes has the advantage of being able to import user databases from those systems. Storing new hashes this way lets you move the password database back to one of those systems. Currently the only other supported system is mediawiki.

LOGGING

Default: please see source-code

This setting is available in Django. RestAuth has (unlike Django) an extensive default. Various views assume the presence of configured loggers, so it is not recommended to change this setting yourself. If you really know what you are doing, read settings.py on how to imitate the required loggers.

LOG_HANDLER

Default: 'logging.StreamHandler'

You can define a different destination of any log messages using LOG_HANDLER. The setting should be a string containing the classname of any available handler. See logging.handlers for whats available. Of course nothing stops you from implementing your own handler.

LOG_HANDLER_KWARGS

Default: {}

Any additional keyword arguments the log handler defined in LOG_HANDLER LoggingHandler will get.

Here is an example for a SocketHandler:

LOG_HANDLER_KWARGS = { 'host': 'localhost', 'port': 10000 }

LOG_LEVEL

Default: 'ERROR'

The default log-level to use. Available values are:

Level Description
CRITICAL Only log errors due to an internal malfunction.
ERROR Also log errors due to misbehaving clients.
WARNING Also log requests where an implicit assumption doesn’t hold. (i.e. when a client assumes that a user exists that in fact does not)
INFO Also log successfully processed requests that change data.
DEBUG Also log idempotent requests, i.e. if a user exists, etc.

MAX_USERNAME_LENGTH

Default: 255

The maximum length of new usernames. Note that this setting might have any effect if a validator restricts the maximum length even further.

MIDDLEWARE_CLASSES

Default:

['django.middleware.common.CommonMiddleware',
 'RestAuth.common.middleware.ExceptionMiddleware',
 'RestAuth.common.middleware.HeaderMiddleware',]

RestAuth uses middlewares like any other Django project. The default however only contains the bare minimum of required middlewares. Various settings (currently CACHES and ENABLE_SESSIONS) influence the effective value of this setting.

Additionally, MIDDLEWARE_CLASSES is a list and not a tuple. This allows you to add your own middleware at any position without having to reconfigure the entire setting. If you do, please consult CACHES and ENABLE_SESSIONS to see how they manipulate MIDDLEWARE_CLASSES to get the effective value.

MIN_PASSWORD_LENGTH

Default: 6

The minimum length for new passwords. This of course only affects new passwords.

MIN_USERNAME_LENGTH

Default: 3

The minimum length of new usernames. Note that this setting might have any effect if a validator restricts the minimum length even further.

SECRET_KEY

Never forget to set a SECRET_KEY in localsettings.py.

SKIP_VALIDATORS

Default: [ 'linux', 'windows', 'email', 'xmpp' ]

What validators to skip to relax the minimum requirements on usernames.

The currently available validators are:

validator restrictions
email todo
linux todo
mediawiki todo
windows todo
xmpp todo