Giters

jazzband / django-axes

Keep track of failed login attempts in Django-powered sites.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Make the `django_ipware` an optional dependency

hirotasoshu opened this issue · comments

commented

Discussed in #1021

commented

Thanks for opening 👍 I made a prerelease for 6.0.0 marked as 6.0.0b1 to PyPI that we can test this in when implemented; we can bake another 6.0.0b2 from this.

commented

@aleksihakli Can we just return request.META.get('REMOTE_ADDR') by default and require users to implement custom get_client_ip method or use django-ipware if more complex logic is required?

The order of preference for address resolution will be:

  1. If configured, use AXES_CLIENT_IP_CALLABLE
  2. If installed, use django-ipware package
  3. Return request.META.get('REMOTE_ADDR')

In that case, all django-ipware related settings should have prefix AXES_IPWARE or smth like that

commented

This is just my personal hunch / opinion but using plain REMOTE_ADDR on a site that has a potential to be in production has a bunch of issues:

  • Usually contains the reverse proxy IP set by the WSGI server implementation
  • Usually people forget to configure the proxy IP settings
  • Is implicit; not explicit

I'd prefer to just raising an error on a missing value and requiring people to install (and hopefully configure) django-ipware as an extra dependency for sane defaults.

Rewriting the django-ipware related configuration flags as AXES_IPWARE_ instead of just AXES_ would indeed be a bit more explicit. I'm wondering how this would be best implemented in terms of backwards compatibility and old flag deprecation? Just document deprecation, document and raise errors on misconfiguration, or implement logic for supporting the old values, too?

commented

I sketched out one option for the optional deps pattern so that we have some basis for further discussion, would appreciate if you can check and highlight any issues or faults you detect in it. All improvement ideas are welcome :)

commented

Well after some pondering the default idea in ipware, too, seems to be to just use request.META["REMOTE_ADDR"] if nothing better is configured and available, and for ease-of-use I'd assume that defaulting to that if we make django-ipware optional would be a good option? I changed the PR draft to use that approach, do check if it seems OK.

commented

This has been implemented and published in the prerelease version 6.0.0b2 to enable feature testing.