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.
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.
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.
Default: True
Linux allows virtually any username, but does not recommend usernames that:
Setting this variable to False causes the linux validator (see SKIP_VALIDATORS) to only apply a more relaxed check. Even when set to False, usernames can only be 32 characters long, may not start with a dash (‘-‘) and may not contain any whitespace character.
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.
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.
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.
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 }
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. |
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.
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.
Default: 6
The minimum length for new passwords. This of course only affects new passwords.
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.
Never forget to set a SECRET_KEY in localsettings.py.
Default: [ 'linux', 'windows', 'email', 'xmpp' ]
What validators to skip to relax the minimum requirements on usernames.
The currently available validators are:
validator | restrictions |
---|---|
todo | |
linux | todo |
mediawiki | todo |
windows | todo |
xmpp | todo |