Django Axes
Django Axes
Release 5.0.4
Jazzband
1 Contents 1
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.8 API reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.9 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.10 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
i
ii
CHAPTER 1
Contents
1.1 Requirements
Axes requires a supported Django version and runs on Python versions 3.6 and above.
Refer to the project source code repository in GitHub and see the Travis CI configuration and
Python package definition to check if your Django and Python version are supported.
The Travis CI builds test Axes compatibility with the Django master branch for future compat-
ibility as well.
1.2 Installation
1
Django Axes Documentation, Release 5.0.4
AUTHENTICATION_BACKENDS = [
# AxesBackend should be the first backend in the AUTHENTICATION_
˓→BACKENDS list.
'axes.backends.AxesBackend',
MIDDLEWARE = [
# The following is the list of default middleware in new Django
˓→projects.
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'axes.middleware.AxesMiddleware',
]
2 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
AXES_ENABLED = False
This disables the Axes middleware, authentication backend and signal handlers which might
produce errors with exotic test configurations.
1.3 Usage
Once Axes is is installed and configured, you can login and logout of your application via
the django.contrib.auth views. The attempts will be logged and visible in the Access
Attempts section in admin.
By default, Axes will lock out repeated access attempts from the same IP address. You can
allow this IP to attempt again by deleting relevant AccessAttempt records.
Records can be deleted, for example, by using the Django admin application.
You can also use the axes_reset, axes_reset_ip, and axes_reset_username
management commands with the Django manage.py command helpers:
• python manage.py axes_reset will reset all lockouts and access records.
• python manage.py axes_reset_ip [ip ...] will clear lockouts and
records for the given IP addresses.
• python manage.py axes_reset_username [username ...] will clear
lockouts and records for the given usernames.
In your code, you can use the axes.utils.reset function.
• reset() will reset all lockouts and access records.
• reset(ip=ip) will clear lockouts and records for the given IP address.
• reset(username=username) will clear lockouts and records for the given user-
name.
Please note that if you give both username and ip arguments to reset that attempts that
have both the set IP and username are reset.
The effective behaviour of reset is to and the terms instead of or ing them.
1.4 Configuration
1.3. Usage 3
Django Axes Documentation, Release 5.0.4
The following settings.py options are available for customizing Axes behaviour.
• AXES_ENABLED: Enable or disable Axes plugin functionality, for example in test runner
setup. Default: True
• AXES_FAILURE_LIMIT: The number of login attempts allowed before a record is
created for the failed logins. Default: 3
• AXES_LOCK_OUT_AT_FAILURE: After the number of allowed login attempts are ex-
ceeded, should we lock out this IP (and optional user agent)? Default: True
• AXES_COOLOFF_TIME: If set, defines a period of inactivity after which old failed login
attempts will be cleared. Can be set to a Python timedelta object or an integer. If an
integer, will be interpreted as a number of hours. Default: None
• AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP: If True, prevent login
from IP under a particular username if the attempt limit has been exceeded, otherwise
lock out based on IP. Default: False
• AXES_ONLY_USER_FAILURES : If True, only lock based on username, and never
lock based on IP if attempts exceed the limit. Otherwise utilize the existing IP and user
locking logic. Default: False
• AXES_USE_USER_AGENT: If True, lock out and log based on the IP address and the
user agent. This means requests from different user agents but from the same IP are
treated differently. This settings has no effect if the AXES_ONLY_USER_FAILURES
setting is active. Default: False
• AXES_LOGGER: If set, specifies a logging mechanism for Axes to use. Default:
'axes.watch_login'
• AXES_HANDLER: The path to to handler class to use. If set, overrides the default signal
handler backend. Default: 'axes.handlers.database.DatabaseHandler'
• AXES_CACHE: The name of the cache for Axes to use. Default: 'default'
• AXES_LOCKOUT_TEMPLATE: If set, specifies a template to render when a user is
locked out. Template receives cooloff_time and failure_limit as context vari-
ables. Default: None
• AXES_LOCKOUT_URL: If set, specifies a URL to redirect to on lockout. If both
AXES_LOCKOUT_TEMPLATE and AXES_LOCKOUT_URL are set, the template will be
used. Default: None
• AXES_VERBOSE: If True, you’ll see slightly more logging for Axes. Default: True
• AXES_USERNAME_FORM_FIELD: the name of the form field that contains your users
usernames. Default: username
• AXES_USERNAME_CALLABLE: A callable or a string path to function that
takes two arguments for user lookups: def get_username(request:
HttpRequest, credentials: dict) -> str: .... This can be
any callable such as AXES_USERNAME_CALLABLE = lambda request,
4 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
Axes makes use of django-ipware package to detect the IP address of the client and uses
some conservative configuration parameters by default for security.
If you are using reverse proxies, you will need to configure one or more of the following settings
to suit your set up to correctly resolve client IP addresses:
1.4. Configuration 5
Django Axes Documentation, Release 5.0.4
Axes uses handlers for processing signals and events from Django authentication and login
attempts.
The following handlers are implemented by Axes and can be configured with the
AXES_HANDLER setting in project configuration:
• axes.handlers.database.AxesDatabaseHandler logs attempts to database
and creates AccessAttempt and AccessLog records that persist until removed from the
database manually or automatically after their cool offs expire (checked on each login
event).
• axes.handlers.cache.AxesCacheHandler only uses the cache for monitor-
ing attempts and does not persist data other than in the cache backend; this data can
be purged automatically depending on your cache configuration, so the cache handler is
by design less secure than the database backend but offers higher throughput and can
perform better with less bottlenecks. The cache backend should ideally be used with a
central cache system such as a Memcached cache and should not rely on individual server
state such as the local memory or file based cache does.
• axes.handlers.dummy.AxesDummyHandler does nothing with attempts and
can be used to disable Axes handlers if the user does not wish Axes to execute any logic
on login signals. Note that this effectively disables any Axes security features, and is
meant to be used on e.g. local development setups and testing deployments where login
monitoring is not wanted.
To switch to cache based attempt tracking you can do the following:
AXES_HANDLER = 'axes.handlers.cache.AxesCacheHandler'
If you are running Axes with the cache based handler on a deployment with a local Django
cache, the Axes lockout and reset functionality might not work predictably if the cache in use
is not the same for all the Django processes.
Axes needs to cache access attempts application-wide, and e.g. the in-memory cache only
caches access attempts per Django process, so for example resets made in the command line
6 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
might not remove lock-outs that are in a sepate processes in-memory cache such as the web
server serving your login or admin page.
To circumvent this problem, please use somethings else than django.core.
cache.backends.dummy.DummyCache, django.core.cache.backends.
locmem.LocMemCache, or django.core.cache.backends.filebased.
FileBasedCache as your cache backend in Django cache BACKEND setting.
If changing the 'default' cache is not an option, you can add a cache specifically for use
with Axes. This is a two step process. First you need to add an extra cache to CACHES with a
name of your choice:
CACHES = {
'axes': {
'BACKEND': 'django.core.cache.backends.memcached.
˓→MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}
The next step is to tell Axes to use this cache through adding AXES_CACHE to your
settings.py file:
AXES_CACHE = 'axes'
Axes requires authentication backends to pass request objects with the authentication requests
for performing monitoring.
If you get AxesBackendRequestParameterRequired exceptions, make sure any li-
braries and middleware you use pass the request object.
Please check the integration documentation for further information.
Refer to the integration documentation for Axes configuration with third party applications and
plugins such as
• Django REST Framework
• Django Allauth
• Django Simple Captcha
1.4. Configuration 7
Django Axes Documentation, Release 5.0.4
1.5 Customization
Axes has multiple options for customization including customizing the attempt tracking and
lockout handling logic and lockout response formatting.
There are public APIs and the whole Axes tracking system is pluggable. You can swap the
authentication backend, attempt tracker, failure handlers, database or cache backends and error
formatters as you see fit.
Check the API reference section for further inspiration on implementing custom authentication
backends, middleware, and handlers.
Axes uses the stock Django signals for login monitoring and can be customized and extended
by using them correctly.
Axes listens to the following signals from django.contrib.auth.signals to log ac-
cess attempts:
• user_logged_in
• user_logged_out
• user_login_failed
You can also use Axes with your own auth module, but you’ll need to ensure that it sends the
correct signals in order for Axes to log the access attempts.
Here is a more detailed example of sending the necessary signals using and a custom auth back-
end at an endpoint that expects JSON requests. The custom authentication can be swapped out
with authenticate and login from django.contrib.auth, but beware that those
methods take care of sending the nessary signals for you, and there is no need to duplicate
them as per the example.
example/forms.py:
class LoginForm(forms.Form):
username = forms.CharField(max_length=128, required=True)
password = forms.CharField(max_length=128, required=True)
example/views.py:
8 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
@method_decorator(axes_dispatch, name='dispatch')
@method_decorator(csrf_exempt, name='dispatch')
class Login(View):
"""
Custom login view that takes JSON credentials
"""
http_method_names = ['post']
if not form.is_valid():
# inform django-axes of failed login
signals.user_login_failed.send(
sender=User,
request=request,
credentials={
'username': form.cleaned_data.get('username'),
},
)
return HttpResponse(status=400)
user = authenticate(
request=request,
username=form.cleaned_data.get('username'),
password=form.cleaned_data.get('password'),
)
signals.user_logged_in.send(
sender=User,
request=request,
user=user,
)
return JsonResponse({
'message':'success'
}, status=200)
1.5. Customization 9
Django Axes Documentation, Release 5.0.4
return HttpResponse(status=403)
urls.py:
urlpatterns = [
path('login/', Login.as_view(), name='login'),
]
In special cases, you may have the need to modify the username that is submitted before
attempting to authenticate. For example, adding namespacing or removing client-set pre-
fixes. In these cases, axes needs to know how to make these changes so that it can
correctly identify the user without any form cleaning or validation. This is where the
AXES_USERNAME_CALLABLE setting comes in. You can define how to make these mod-
ifications in a callable that takes a request object and a credentials dictionary, and provide that
callable to axes via this setting.
For example, a function like this could take a post body with something like
username='prefixed-username' and namespace=my_namespace and turn it
into my_namespace-username:
example/utils.py:
settings.py:
AXES_USERNAME_CALLABLE = 'example.utils.get_username'
NOTE: You still have to make these modifications yourself before calling authenticate. If you
want to re-use the same function for consistency, that’s fine, but Axes does not inject these
changes into the authentication flow for you.
10 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
1.6 Integration
Axes is intended to be pluggable and usable with 3rd party authentication solutions.
This document describes the integration with some commonly used 3rd party packages such as
Django Allauth and Django REST Framework.
AXES_USERNAME_FORM_FIELD = 'login'
example/forms.py:
class AxesLoginForm(LoginForm):
"""
Extended login form class that supplied the
user credentials for Axes compatibility.
"""
def user_credentials(self):
credentials = super(AllauthCompatLoginForm, self).user_
˓→credentials()
credentials['login'] = credentials.get('email') or
˓→credentials.get('username')
return credentials
example/urls.py:
1.6. Integration 11
Django Axes Documentation, Release 5.0.4
LoginView.dispatch = method_decorator(axes_dispatch)(LoginView.
˓→dispatch)
LoginView.form_invalid = method_decorator(axes_form_
˓→invalid)(LoginView.form_invalid)
urlpatterns = [
# Override allauth default login view with a patched view
url(r'^accounts/login/$', LoginView.as_view(form_
˓→class=AllauthCompatLoginForm), name='account_login'),
url(r'^accounts/', include('allauth.urls')),
]
Modern versions of Django REST Framework after 3.7.0 work normally with Axes.
Django REST Framework versions prior to [3.7.0](https://github.com/encode/
django-rest-framework/commit/161dc2df2ccecc5307cdbc05ef6159afd614189e) require
the request object to be passed for authentication.
example/authentication.py:
class AxesBasicAuthentication(BasicAuthentication):
"""
Extended basic authentication backend class that supplies the
request object into the authentication call for Axes
˓→compatibility.
NOTE: This patch is only needed for DRF versions < 3.7.0.
"""
credentials = {
get_user_model().USERNAME_FIELD: userid,
'password': password
(continues on next page)
12 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
if user is None:
raise exceptions.AuthenticationFailed(_('Invalid
˓→username/password.'))
if not user.is_active:
raise exceptions.AuthenticationFailed(_('User inactive
˓→or deleted.'))
Axes supports Captcha with the Django Simple Captcha package in the following manner.
settings.py:
AXES_LOCKOUT_URL = '/locked'
example/urls.py:
example/forms.py:
class AxesCaptchaForm(forms.Form):
captcha = CaptchaField()
example/views.py:
def locked_out(request):
if request.POST:
form = AxesCaptchaForm(request.POST)
if form.is_valid():
ip = get_ip_address_from_request(request)
reset(ip=ip)
return HttpResponseRedirect(reverse_lazy('signin'))
else:
form = AxesCaptchaForm()
(continues on next page)
1.6. Integration 13
Django Axes Documentation, Release 5.0.4
example/templates/example/captcha.html:
{{ form.captcha.errors }}
{{ form.captcha }}
<div class="form-actions">
<input type="submit" value="Submit" />
</div>
</form>
1.7 Architecture
Axes is based on the existing Django authentication backend architecture and framework for
recognizing users and aims to be compatible with the stock design and implementation of
Django while offering extensibility and configurability for using the Axes authentication moni-
toring and logging for users of the package as well as 3rd party package vendors such as Django
REST Framework, Django Allauth, Python Social Auth and so forth.
The development of custom 3rd party package support are active goals, but you should check
the up-to-date documentation and implementation of Axes for current compatibility before
using Axes with custom solutions and make sure that authentication monitoring is working
correctly.
This document describes the Django authentication flow and how Axes augments it to achieve
authentication and login monitoring and lock users out on too many access attempts.
When a user tries to log in in Django, the login is usually performed by running a number of
authentication backends that check user login information by calling the django.contrib.
auth.authenticate function.
If an authentication backend does not approve of a user login, it can raise a django.core.
exceptions.PermissionDenied exception.
If a login fails, Django then fires a from django.contrib.auth.signals.
user_login_failed signal.
If this signal raises an exception, it is propagated through the Django middleware stack where it
can be caught, or alternatively where it can bubble up to the default Django exception handlers.
14 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
2. django.contrib.auth.authenticate is called by
the view code to check the authentication request
for credentials and return a user object matching them.
Axes monitors logins with the user_login_failed signal handler and after login attempts
exceed the given maximum, starts blocking them.
Django emits the user_login_failed signal when an authentication backend either raises
the PermissionDenied signal or alternatively no authentication backend manages to recognize
a given authentication request and return a user for it.
The blocking is done by AxesBackend which checks every request coming through the
Django authentication flow and verifies they are not blocked, and allows the requests to go
through if the check passes.
If any of the checks fails, an exception is raised which interrupts the login process and triggers
the Django login failed signal handlers.
Another exception is raised by a Axes signal handler, which is then caught by
AxesMiddleware and converted into a readable error because the user is currently locked
out of the system.
Axes implements the lockout flow as follows:
2. django.contrib.auth.authenticate is called.
1.7. Architecture 15
Django Axes Documentation, Release 5.0.4
This plugin assumes that the login views either call the django.contrib.auth.
authenticate method to log in users or otherwise take care of notifying Axes of authenti-
cation attempts or login failures the same way Django does.
The login flows can be customized and the Axes authentication backend or middleware can be
easily swapped.
Axes offers extensible APIs that you can customize to your liking. You can specialize the
following base classes or alternatively use third party modules as long as they implement the
following APIs.
class axes.handlers.base.AxesHandler
Handler API definition for implementations that are used by the AxesProxyHandler.
If you wish to specialize your own handler class, override the necessary methods and con-
figure the class for use by setting settings.AXES_HANDLER = 'module.path.
to.YourClass'.
The default implementation that is actually used by Axes is axes.handlers.
database.AxesDatabaseHandler.
16 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
Note: This is a virtual class and can not be used without specialization.
Note: This backend does not log your user in. It monitors login at-
tempts. Authentication is handled by the following backends that are configured in
AUTHENTICATION_BACKENDS.
class axes.backends.AxesModelBackend
Bases: axes.backends.AxesBackend
Backwards compatibility class for version 4 to version 5 migration.
See the AxesBackend class documentation and implementation.
class axes.middleware.AxesMiddleware(get_response: Callable)
Middleware that calculates necessary HTTP request attributes for attempt monitoring and
maps lockout signals into readable HTTP 403 Forbidden responses.
By default Django server returns PermissionDenied exceptions as HTTP 403 errors
with the django.views.defaults.permission_denied view that renders the
403.html template from the root template directory if found.
This middleware recognizes the specialized attempt monitoring and lockout exceptions
and uses the axes.helpers.get_lockout_response handler for returning cus-
tomizable and context aware lockout message to the end user.
To customize the error handling behaviour further, you can subclass this middleware and
change the process_exception handler to your own liking.
Please see the following configuration flags before customizing this handler:
• AXES_LOCKOUT_TEMPLATE,
• AXES_LOCKOUT_URL,
• AXES_COOLOFF_MESSAGE, and
• AXES_PERMALOCK_MESSAGE.
class axes.request.AxesHttpRequest
Bases: django.http.request.HttpRequest
Extended Django HttpRequest with custom Axes attributes.
This request is constructed by the AxesMiddleware class where the custom attributes
are inserted into the request.
18 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
Note: The str type variables have a maximum length of 255 characters and they are
calculated in the middleware layer. If the HTTP request attributes can not be resolved
they are assigned default value of <unknown>.
Variables
• axes_attempt_time (datetime) – Timestamp of the request
on the server side.
• axes_ip_address (str) – Request IP address as resolved by
django-axes and django-ipware configurations.
• axes_user_agent (str) – Request agent from request.
META['HTTP_USER_AGENT'].
• axes_path_info (str) – Request path from request.
META['PATH_INFO'].
• axes_http_accept (str) – Request Accept header from
request.META['HTTP_ACCEPT'].
1.9 Development
You can contribute to this project forking it from GitHub and sending pull requests.
First fork the repository and then clone it:
$ mkdir -p ~/.virtualenvs
$ python3 -m venv ~/.virtualenvs/django-axes
$ source ~/.virtualenvs/django-axes/bin/activate
$ cd django-axes
$ pip install -r requirements.txt
Unit tests are located in the axes/tests folder and can be easily run with the pytest tool:
$ pytest
Prospector runs a number of source code style, safety, and complexity checks:
$ prospector
Mypy runs static typing checks to verify the source code type annotations and correctness:
1.9. Development 19
Django Axes Documentation, Release 5.0.4
$ mypy .
Before committing, you can run all the above tests against all supported Python and Django
versions with tox:
$ tox
Tox runs the same test set that is run by Travis, and your code should be good to go if it passes.
If you wish to limit the testing to specific environment(s), you can parametrize the tox run:
$ tox -e py37-django21
After you have pushed your changes, open a pull request on GitHub for getting your code
upstreamed.
1.10 Changes
• Fix regression with OAuth2 authentication backends not having remote IP addresses set
and throwing an exception in cache key calculation. [aleksihakli]
• Add AXES_ENABLED setting for disabling Axes with e.g. tests that use Django
test client login, logout, and force_login methods, which do not supply the
request argument to views, preventing Axes from functioning correctly in certain test
setups. [aleksihakli]
20 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
• Removed duplicated check that was causing issues when using APIs. [camilonova]
• Added Russian translations [lubicz-sielski]
1.10. Changes 21
Django Axes Documentation, Release 5.0.4
• fix missing migration and add check to prevent it happening again. [markddavidoff]
• Change custom authentication backend failures from error to warning log level [aleksi-
hakli]
22 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
• Set up strict code linting for CI pipeline that fails builds if linting does not pass [aleksi-
hakli]
• Clean up old code base and tests based on linter errors [aleksihakli]
1.10. Changes 23
Django Axes Documentation, Release 5.0.4
• BREAKING CHANGES. Support for Django >= 1.11 and signals, see issue #215. Drop
support for Python < 3.6 [camilonova]
24 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
• Improve the logic when using a reverse proxy to avoid possible attacks. [camilonova]
1.10. Changes 25
Django Axes Documentation, Release 5.0.4
26 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
• added initial migration files to support django 1.7 &up. Upgrading users should run
migrate –fake-initial after update [ibaguio]
• Add db indexes to CommonAccess model [Schweigi]
1.10. Changes 27
Django Axes Documentation, Release 5.0.4
• Reduce logging of reverse proxy IP lookup and use configured logger. Fixes #76. Instead
of logging the notice that django.axes looks for a HTTP header set by a reverse proxy on
each attempt, just log it one-time on first module import. Also use the configured logger
(by default axes.watch_login) for the message to be more consistent in logging. [eht16]
• Limit the length of the values logged into the database. Refs #73 [camilonova]
• Refactored tests to be more stable and faster [camilonova]
• Clean client references [camilonova]
• Fixed admin login url [camilonova]
• Added django 1.7 for testing [camilonova]
• Travis file cleanup [camilonova]
• Remove hardcoded url path [camilonova]
• Fixing tests for django 1.7 [Andrew-Crosio]
• Fix for django 1.7 exception not existing [Andrew-Crosio]
• Removed python 2.6 from testing [camilonova]
• Use django built-in six version [camilonova]
• Added six as requirement [camilonova]
• Added python 2.6 for travis testing [camilonova]
• Replaced u string literal prefixes with six.u() calls [amrhassan]
• Fixes object type issue, response is not an string [camilonova]
• Python 3 compatibility fix for db_reset [nicois]
• Added example project and helper scripts [barseghyanartur]
• Admin command to list login attemps [marianov]
• Replaced six imports with django.utils.six ones [amrhassan]
• Replaced u string literal prefixes with six.u() calls to make it compatible with Python 3.2
[amrhassan]
• Replaced assertIn‘s and ‘assertNotIn‘s with ‘assertContains and assertNotContains
[fcurella]
• Added py3k to travis [fcurella]
• Update test cases to be python3 compatible [nicois]
• Python 3 compatibility fix for db_reset [nicois]
• Removed trash from example urls [barseghyanartur]
• Added django installer [barseghyanartur]
• Added example project and helper scripts [barseghyanartur]
28 Chapter 1. Contents
Django Axes Documentation, Release 5.0.4
1.10. Changes 29
Django Axes Documentation, Release 5.0.4
30 Chapter 1. Contents
CHAPTER 2
• search
31
Django Axes Documentation, Release 5.0.4
a
axes.backends, 18
axes.handlers.base, 16
axes.middleware, 18
axes.request, 18
33
Django Axes Documentation, Release 5.0.4
A (axes.handlers.base.AxesHandler
axes.backends (module), 18 method), 17
axes.handlers.base (module), 16 post_save_access_attempt()
axes.middleware (module), 18 (axes.handlers.base.AxesHandler
axes.request (module), 18 method), 17
AxesBackend (class in axes.backends), 18
AxesHandler (class in
U
axes.handlers.base), 16 user_logged_in()
AxesHttpRequest (class in axes.request), (axes.handlers.base.AxesHandler
18 method), 17
AxesMiddleware (class in user_logged_out()
axes.middleware), 18 (axes.handlers.base.AxesHandler
AxesModelBackend (class in method), 17
axes.backends), 18 user_login_failed()
(axes.handlers.base.AxesHandler
G method), 17
get_failures()
(axes.handlers.base.AxesHandler
method), 17
I
is_allowed()
(axes.handlers.base.AxesHandler
method), 17
is_blacklisted()
(axes.handlers.base.AxesHandler
method), 17
is_locked()
(axes.handlers.base.AxesHandler
method), 17
is_whitelisted()
(axes.handlers.base.AxesHandler
method), 17
P
post_delete_access_attempt()
35