Axes is in INSTALLED_APPS and AUTHENTICATION_BACKENDS. Version : 5.5.0

When trying to run my CI and just test runner I got this :

Here is the traceback : Traceback (most recent call last): File "manage.py", line 38, in execute_from_command_line(sys.argv) File "/usr/local/lib/python3.7/site-packages/django/core/management/init.py", line 381, in execute_from_command_line utility.execute() File "/usr/local/lib/python3.7/site-packages/django/core/management/init.py", line 357, in execute django.setup() File "/usr/local/lib/python3.7/site-packages/django/init.py", line 24, in setup apps.populate(settings.INSTALLED_APPS) File "/usr/local/lib/python3.7/site-packages/django/apps/registry.py", line 122, in populate app_config.ready() File "/var/www/jung/badoom/core/apps.py", line 20, in ready autodiscover_modules("signals") File "/usr/local/lib/python3.7/site-packages/django/utils/module_loading.py", line 47, in autodiscover_modules import_module('%s.%s' % (app_config.name, module_to_search)) File "/usr/local/lib/python3.7/importlib/init.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1006, in _gcd_import File "", line 983, in _find_and_load File "/usr/local/lib/python3.7/site-packages/ddtrace/internal/import_hooks.py", line 215, in wrapped_find_and_load_unlocked return exec_and_call_hooks(module_name, wrapped, args, kwargs) File "/usr/local/lib/python3.7/site-packages/ddtrace/internal/import_hooks.py", line 171, in exec_and_call_hooks return wrapped(*args, **kwargs) File "", line 967, in _find_and_load_unlocked File "", line 677, in _load_unlocked File "", line 728, in exec_module File "", line 219, in _call_with_frames_removed File "/usr/local/lib/python3.7/site-packages/axes/signals.py", line 15, in from axes.handlers.proxy import AxesProxyHandler File "", line 983, in _find_and_load File "/usr/local/lib/python3.7/site-packages/ddtrace/internal/import_hooks.py", line 215, in wrapped_find_and_load_unlocked return exec_and_call_hooks(module_name, wrapped, args, kwargs) File "/usr/local/lib/python3.7/site-packages/ddtrace/internal/import_hooks.py", line 171, in exec_and_call_hooks return wrapped(*args, **kwargs) File "/usr/local/lib/python3.7/site-packages/axes/handlers/proxy.py", line 16, in log = getLogger(settings.AXES_LOGGER) File "/usr/local/lib/python3.7/site-packages/django/conf/init.py", line 80, in getattr val = getattr(self._wrapped, name) AttributeError: 'Settings' object has no attribute 'AXES_LOGGER'

I know we can skip Axes in test but I would prefer to fix this issue, any insight ?

I'm a little concerned by the change to use ipware.ip.get_ip() in v4.

1. There is no documentation to suggest that django-ipware may need to be configured.
2. There is now no documentation on the potential attack vector if the proxy doesn't set X-Forwarded-For (or whatever the first header used in IPWARE_META_PRECEDENCE_ORDER is) explicitly, c.f. USE_X_FORWARDED_HOST
3. ~~django-ipware says to use get_ip() if the server is not accessible on the Internet, see here.~~ (Although looking at the code the distinction between get_ip() and get_real_ip(), the latter doesn't count private IP addresses as "real". What they really mean here is use get_ip() if there are also clients that may connect from an internal private network otherwise use get_real_ip().)
4. Previously django-axes allowed configuring the maximum number of proxies in case of spoofed entries. This is no longer possible. django-ipware provides get_trusted_ip() but it isn't particularly useful in it's current form.

It would probably be wise to recommend setting IPWARE_META_PRECEDENCE_ORDER to ['HTTP_X_FORWARDED_FOR', 'REMOTE_ADDR'] or at least indicate that this was the original behaviour. Checking all of these headers by default feels risky.

Forgive me, but this feels rushed and ill thought through. It was working fine for me and issue #275 and pull request #280 fail to even give any evidence of a problem. Every comment in #275 is regarding AttributeError when looking up META on NoneType - django-ipware is still using request.META. This feels like a push to remove code in favour of a dependency for minor gain.

Hi everyone.

I just did a bunch of changes to use the Django auth signals, so I suppose a lot of things may have changed.

It is possible to be some broken tests but I already tested on a Django 1.11 project and works pretty fine.

Please feel free to add comments or suggestions, and help me out fixing or improving tests. I won't have much time to work on them in the next couple weeks, but I would like this to be merged soon.

any help is very much appreciated.

(Hey everyone, thanks for making axes such a wonderful project! I know a lot of hard work was put into this!)

I've been using django-axes for nearly a year (edit: since 4.5.x) without any problems, and recently upgraded from 5.0.18 to 5.0.19 and my unit tests now indicate that lockouts are no longer working.

The lockouts are based on user login plus IP. We are using axes with django_rest_framework 3.8.2 and django_allauth 0.40.0.

Some relevant settings:

AUTHENTICATION_BACKENDS = (
    "axes.backends.AxesBackend",
    "django.contrib.auth.backends.ModelBackend",
    "allauth.account.auth_backends.AuthenticationBackend",
}
CACHES = {
    "default": {"BACKEND": "django.core.cache.backends.locmem.LocMemCache"},
    "axes_cache": {"BACKEND": "django.core.cache.backends.dummy.DummyCache"},
}
AXES_CACHE = "axes_cache"
AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP = True

With axes 5.0.18, after two unsuccessful local attempts against the same login:

[in]: from axes.models import AccessAttempt
[in]: qs = AccessAttempt.objects.all()
[in]: len(qs)
[out]: 1

[in]: attempt = qs.first()
[in]: vars(attempt)
[out]:
{'_state': <django.db.models.base.ModelState at 0x7fd6214d5dd8>,
 'id': 68,
 'user_agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36',
 'ip_address': '127.0.0.1',
 'username': '[email protected]',
 'http_accept': 'application/json',
 'path_info': '/account/login/',
 'attempt_time': datetime.datetime(2019, 11, 28, 21, 22, 5, 592513, tzinfo=<UTC>),
 'get_data': '\n---------\n',
 'post_data': '[email protected]\n---------\[email protected]',
 'failures_since_start': 2}

With 5.0.18 both attempts are correctly represented by the same model instance.

After upgrading to axes 5.0.19, when I run the same test as above:

[in]: qs = AccessAttempt.objects.all()
[in]: len(qs)
[out]: 2

[in]: a_1 = qs.first()
[in]: a_2 = qs.last()
[in]: vars(a_1)
[out]:
{'_state': <django.db.models.base.ModelState at 0x7f20ebe4ae48>,
 'id': 69,
 'user_agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36',
 'ip_address': '127.0.0.1',
 'username': '[email protected]',
 'http_accept': 'application/json',
 'path_info': '/account/login/',
 'attempt_time': datetime.datetime(2019, 11, 28, 21, 27, 7, 300416, tzinfo=<UTC>),
 'get_data': '',
 'post_data': '[email protected]',
 'failures_since_start': 1}

[in]: vars(a_2)
[out]:
{'_state': <django.db.models.base.ModelState at 0x7f20ebe4aa20>,
 'id': 70,
 'user_agent': 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36',
 'ip_address': '127.0.0.1',
 'username': '[email protected]',
 'http_accept': 'application/json',
 'path_info': '/account/login/',
 'attempt_time': datetime.datetime(2019, 11, 28, 21, 27, 8, 883077, tzinfo=<UTC>),
 'get_data': '',
 'post_data': '[email protected]',
 'failures_since_start': 1}

With 5.0.19, both attempts with the same login and IP are recorded to separate model instances and there is no lockout on subsequent attempts.

Has anyone else experienced anything like this?

As previously mentioned in #358 the AXES_ONLY_USER_FAILURES setting only works if the login is performed using a Form request. If logging in using JSON, Axes can properly save the failed logins, but is unable to find an existing entry in the axes_attempts table or in cache due to relying on request.POST to find the username.

I changed this to make use of the credentials or username fields wherever possible, added new tests for thsi behavior and updated the documentation.

When available, credentials is passed along until it reaches the get_client_username in utils.py. If credentials is not available to be forwarded, but the parsed username from login is available otherwise, a dummy credentials dictionary is created with the settings.AXES_USERNAME_FORM_FIELD key and the username inside it. Only if none of these are availeble the old way to get the username directly from request,POST is attempted. This mainly affects the decorators for the Login forms, but there's neither a good way to access the username otherwise nor will these usually be manipulated to not send a form request for the login.

Last but not least, I had to introduce a breaking change: The AXES_USERNAME_CALLABLE function now receives the credentials dictionary as additional parameter.

I think this should also fix #376 as I've just replaced the manual logic for looking up the username from the request with callng get_client_username instead

Hi guys,

following thing: I'm using django-rest-framework and want to secure my backend with axes.

When I use the default database table type "InnoDB" axes cannot save or update failed attempts in the tables. When I change the table type to "MyIsam", it works.

I just updated to the latest version. Same as before. Super strange but I couldn't figure out why this happens.

Best Ronny

Since version 5, when using the login and force_login methods of the django test client (django version 1.11), exceptions get thrown and tests fail.

When using force_login() the django test client uses an instance of HttpRequest, but axes requires an AxesHttpRequest.

from django.test import Client
client = Client()
client.force_login(user)

Traceback (most recent call last):
  File "/vagrant/src/project/tests/tests_integration.py", line 87, in setUp
    client.force_login(user)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/test/client.py", line 645, in force_login
    self._login(user, backend)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/test/client.py", line 658, in _login
    login(request, user, backend)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/contrib/auth/__init__.py", line 161, in login
    user_logged_in.send(sender=user.__class__, request=request, user=user)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/dispatch/dispatcher.py", line 193, in send
    for receiver in self._live_receivers(sender)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/dispatch/dispatcher.py", line 193, in <listcomp>
    for receiver in self._live_receivers(sender)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/axes/signals.py", line 26, in handle_user_logged_in
    AxesProxyHandler.user_logged_in(*args, **kwargs)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/axes/handlers/proxy.py", line 52, in user_logged_in
    return cls.get_implementation().user_logged_in(sender, request, user, **kwargs)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/axes/handlers/database.py", line 141, in user_logged_in
    clean_expired_user_attempts(request.axes_attempt_time)
AttributeError: 'HttpRequest' object has no attribute 'axes_attempt_time'

When using login() the test client uses request=None to authenticate.

from django.test import Client
client = Client()
client.login(user=user.email, password="SecurePassword123")

Traceback (most recent call last):
  File "/vagrant/src/project/tests/tests_integration.py", line 89, in setUp
    client.login(user=user.email, password="SecurePassword123")
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/test/client.py", line 628, in login
    user = authenticate(**credentials)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/contrib/auth/__init__.py", line 70, in authenticate
    user = _authenticate_with_backend(backend, backend_path, request, credentials)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/django/contrib/auth/__init__.py", line 116, in _authenticate_with_backend
    return backend.authenticate(*args, **credentials)
  File "/home/vagrant/.local/share/virtualenvs/vagrant-gKDsaKU3/lib/python3.6/site-packages/axes/backends.py", line 33, in authenticate
    raise AxesBackendRequestParameterRequired('AxesBackend requires a request as an argument to authenticate')
axes.exceptions.AxesBackendRequestParameterRequired: AxesBackend requires a request as an argument to authenticate

I would like to only enable django-axes for staff accounts (preferably only admin site). According to the documentation this is currently not possible (I can't find anything about it). Is it true? Thanks!

@camilonova First Draft for input.

USAGE

settings.py

AUTHENTICATION_BACKENDS = [
    'axes.middleware.DjangoAxesAuthBackend',
    'django.contrib.auth.backends.ModelBackend',
]

login view call example

user = User.objects.get(email=form.cleaned_data['email'])
response_context = {}
user = authenticate(
    request=request,
    username=user.username,
    password=form.cleaned_data['password'],
    response_context=response_context
)
...
if 'error' not in context:
    # if don't have a more specific error, use a generic one.
    context['error'] = 'Incorrect Login Information'
render(request, 'log_in.html', context)

This PR enhances external logging for the project in three ways:

• Log messages contain the correct attributes of the request, when VERBOSE = False.
• Log messages contain detailed information about the request when VERBOSE = True.
• Adds a log message for successful login if DISABLE_SUCCESS_ACCESS_LOG = False.

Accurate logging messages are dependent on the configuration. Settings that it looks at:

• AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP
• AXES_ONLY_USER_FAILURES
• USE_USER_AGENT
• VERBOSE

Log messages were only accurate for the default setting, which exclusively blocks by IP address.

Below is an example the before and after, for logs from a lockout based on IP username, where AXES_LOCK_OUT_BY_COMBINATION_USER_AND_IP = True.

Before:

[2017-04-25 20:20:26,474] [INFO] [axes.watch_login] AXES: BEGIN LOG
[2017-04-25 20:20:26,474] [INFO] [axes.watch_login] AXES: Using django-axes 2.3.2
[2017-04-25 20:20:32,361] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:20:32,473] [INFO] [axes.watch_login] AXES: New login failure by 10.2.3.1. Creating access record.
[2017-04-25 20:20:33,841] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:20:34,000] [INFO] [axes.watch_login] AXES: Repeated login failure by 10.2.3.1. Updating access record. Count = 2
[2017-04-25 20:20:35,149] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:20:35,290] [INFO] [axes.watch_login] AXES: Repeated login failure by 10.2.3.1. Updating access record. Count = 3
[2017-04-25 20:20:35,292] [WARNING] [axes.watch_login] AXES: locked out 10.2.3.1 after repeated login attempts.

After:

[2017-04-25 20:18:27,057] [INFO] [axes.watch_login] AXES: BEGIN LOG
[2017-04-25 20:18:27,058] [INFO] [axes.watch_login] AXES: Using django-axes 2.3.2
[2017-04-25 20:18:27,058] [INFO] [axes.watch_login] AXES: blocking by combination of username and IP.
[2017-04-25 20:18:35,321] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:18:35,445] [INFO] [axes.watch_login] AXES: New login failure by [email protected] from 10.2.3.1. Creating access record.
[2017-04-25 20:18:36,570] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:18:36,701] [INFO] [axes.watch_login] AXES: Repeated login failure by [email protected] from 10.2.3.1. Updating access record. Count = 2 of 3
[2017-04-25 20:18:37,630] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 20:18:37,763] [INFO] [axes.watch_login] AXES: Repeated login failure by [email protected] from 10.2.3.1. Updating access record. Count = 3 of 3
[2017-04-25 20:18:37,765] [WARNING] [axes.watch_login] AXES: locked out [email protected] from 10.2.3.1 after repeated login attempts.

If VERBOSE is set, then detailed information about the request that triggered the event is logged:

• Username
• IP Address
• User agent
• Requested path

This is highly useful information when fed into an external SIEM or logging service, like ELK or Splunk, and used for correlation.

[2017-04-25 21:50:08,638] [INFO] [axes.watch_login] AXES: BEGIN LOG
[2017-04-25 21:50:08,638] [INFO] [axes.watch_login] AXES: Using django-axes 2.3.2
[2017-04-25 21:50:08,638] [INFO] [axes.watch_login] AXES: blocking by combination of username and IP.
[2017-04-25 21:50:31,896] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 21:50:32,016] [INFO] [axes.watch_login] AXES: New login failure by {user: '[email protected]', ip: '10.2.3.1', user-agent: 'Lynx/2.8.8dev.3 libwww-FM/2.14 SSL-MM/1.4.1', path: '('/api/auth/login/',)'}. Creating access record.
[2017-04-25 21:50:33,466] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 21:50:33,589] [INFO] [axes.watch_login] AXES: Repeated login failure by {user: '[email protected]', ip: '10.2.3.1', user-agent: 'Lynx/2.8.8dev.3 libwww-FM/2.14 SSL-MM/1.4.1', path: '/api/auth/login/'}. Updating access record. Count = 2 of 3
[2017-04-25 21:50:34,730] [INFO] [axes.watch_login] AXES: Calling decorated function: LoginView
[2017-04-25 21:50:34,850] [INFO] [axes.watch_login] AXES: Repeated login failure by {user: '[email protected]', ip: '10.2.3.1', user-agent: 'Lynx/2.8.8dev.3 libwww-FM/2.14 SSL-MM/1.4.1', path: '/api/auth/login/'}. Updating access record. Count = 3 of 3
[2017-04-25 21:50:34,851] [WARNING] [axes.watch_login] AXES: locked out {user: '[email protected]', ip: '10.2.3.1', user-agent: 'Lynx/2.8.8dev.3 libwww-FM/2.14 SSL-MM/1.4.1', path: '/api/auth/login/'} after repeated login attempts.

Finally, capturing successful authentication events in external services may be desirable to track user sessions, detect when brute force has succeeded, or some other use case. When DISABLE_SUCCESS_ACCESS_LOG = False, a log message will be generated for successful authentication.

[2017-04-25 22:38:34,545] [INFO] [axes.watch_login] AXES: New login failure by [email protected] from 10.2.3.1. Creating access record.
[2017-04-25 22:38:36,995] [INFO] [axes.watch_login] AXES: Repeated login failure by [email protected] from 10.2.3.1. Updating access record. Count = 2 of 3
[2017-04-25 22:38:40,477] [INFO] [axes.watch_login] AXES: Successful login by [email protected] from 10.2.3.1. Creating access record.

https://github.com/jazzband/django-axes/blob/master/axes/signals.py#L59

Should the following:

        for attempt in attempts:
            failures = max(failures, attempt.failures_since_start)

be modified to:

        for attempt in attempts:
            failures += attempt.failures_since_start

Given that settings.AXES_ONLY_USER_FAILURES maybe return multiple attempts from the same user (different path or data). Wouldn't it make sense for all failed attempts to be summed together? 🤔 💭

Thanks!

Bumps tox from 4.0.16 to 4.1.2.