Django: SocialApp matching query does not exist - django

I'm using django-allauth, and I configured localhost:9000/admin/ with the following details:
socialapp .
provider:
Name:
Client id:
App ID, or consumer key
Key:
Secret: etc .
I set SITE_ID = 2 (because I changed the default site example.com to localhost:9000)
In settings.py:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
'django.contrib.admin',
'uni_form',
'allauth',
'allauth.account',
'allauth.socialaccount',
'bootstrapform',
# 'allauth.socialaccount.providers.twitter',
# 'allauth.socialaccount.providers.openid',
'allauth.socialaccount.providers.facebook',
)
SOCIALACCOUNT_PROVIDERS = \
{ 'facebook':
{ 'SCOPE': ['email', 'publish_stream'],
'AUTH_PARAMS': { 'auth_type': 'reauthenticate' },
'METHOD': 'oauth2' ,
'LOCALE_FUNC': 'path.to.callable'} }
When I go to:
http://localhost:9000/accounts/facebook/login
I get:
Error : `SocialApp matching query does not exist.
What am I doing wrong?

Using the Django admin you need to create a SocialApp listing your Facebook app credentials. Make sure that this app is attached to the proper site (as in, django.contrib.sites.models.Site).
In your case, there needs to be a django.contrib.sites.models.Site instance with id=2 (check the sites admin) that is listed as a site for the SocialApp.
If either the SocialApp is missing, or if it is created but not attached to a site matching your settings.SITE_ID, then allauth does not know what app to pick, resulting in the error message you listed above.

In my case, on the Add social application page, I forgot to select my site as "Chosen sites" 🤦🏼‍♂️
See screenshot below (on the bottom right is the Chosen Sites list):

For me, it showed this error when I had in settings.py:
SITE_ID = 1
It worked when I changed it to 2:
SITE_ID = 2

Step 1: Go to your admin page.
Find social application
Step 2: now add the lines like the following image.
Give your client id and secret key given by google api and move available site (example.com) to chosen sites
Step 3: Now go to sites in the side navigation of admin page and customize like the following image and save it
Step 4: now, add, SITE_ID = 1 in settings.py file.

As an alternative to putting that into the admin, you can also put it in your settings like so: (At least in 2022 with version django-allauth==0.45.0
SOCIALACCOUNT_PROVIDERS = {
'discord': {
# From https://developer.twitter.com
'APP': {
'client_id': os.environ['TWITTER_API_KEY'],
'secret': os.environ['TWITTER_API_SECRET'],
'key': os.environ['TWITTER_APP_ID'],
}
},
'twitter': {
# From https://developer.twitter.com
'APP': {
'client_id': os.environ['TWITTER_API_KEY'],
'secret': os.environ['TWITTER_API_SECRET'],
'key': os.environ['TWITTER_APP_ID'],
}
},
}
Documentation is at: https://django-allauth.readthedocs.io/en/latest/installation.html and https://django-allauth.readthedocs.io/en/latest/configuration.html

It is possible that Django created an 'example.com' site for you already (if it's not a new project). So if this is the case you will need to delete that entry from the Sites admin page AND change the SITE_ID in settings.py to be the correct ID (probably 2 rather than 1).
Consider playing around with the SITE_ID value. For example: SITE_ID = 3, etc.

FWIW, if configuration via the DB is giving you problems, note that you can also use configuration in settings:
SOCIALACCOUNT_PROVIDERS = {
"google": {
"APP": {
"client_id": os.environ[("GOOGLE_OAUTH_CLIENT_ID"],
"secret": os.environ[("GOOGLE_OAUTH_SECRET"],
},
},
}
#Penners

Related

Django saml2 login missing session variables

For my Django application, I am trying to enable SSO using Djangosaml2 and following are the versions I am using
djangosaml2==1.2.0
pysaml2==7.0.0
djangorestframework==3.12.2
Django==3.1.7
python==3.8
My saml2_settings is as follows
from os import path
import saml2
import saml2.saml
from app.local_settings import SERVER_URL
AUTHENTICATION_BACKENDS = (
'django.contrib.auth.backends.ModelBackend',
'djangosaml2.backends.Saml2Backend',
)
SAML_SESSION_COOKIE_NAME = 'saml_session'
SAML_ATTRIBUTE_MAPPING = {
'username': ('username', ),
'email': ('email', ),
'first_name': ('first_name', ),
'last_name': ('last_name', ),
}
BASEDIR = path.dirname(path.abspath(__file__))
SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
LOGIN_URL = '/saml2/login/'
LOGOUT_URL = '/saml2/logout/'
SESSION_EXPIRE_AT_BROWSER_CLOSE = True
SAML_CREATE_UNKNOWN_USER = True
SAML_SERVER_URL = '10.23.1.114'
SAML_ENABLED = True
# MIDDLEWARE.append('djangosaml2.middleware.SamlSessionMiddleware')
SAML_CONFIG = {
# full path to the xmlsec1 binary programm
'xmlsec_binary': '/usr/bin/xmlsec1',
# your entity id, usually your subdomain plus the url to the metadata view
'entityid': path.join(SAML_SERVER_URL, 'saml2/metadata'),
# directory with attribute mapping
'attribute_map_dir': path.join(BASEDIR, 'attribute_maps'),
# this block states what services we provide
'service': {
# we are just a lonely SP
'sp' : {
'name': 'Dummy app',
'allow_unsolicited': True,
'authn_requests_signed': True,
'force_authn': True,
'want_response_signed': True,
'want_assertions_signed': True,
'logout_requests_signed': True,
'name_id_format_allow_create': False,
'endpoints': {
# url and binding to the assetion consumer service view
# do not change the binding or service name
'assertion_consumer_service': [
(path.join(SAML_SERVER_URL, 'saml2/acs/'),
saml2.BINDING_HTTP_POST),
],
# url and binding to the single logout service view
# do not change the binding or service name
'single_logout_service': [
(path.join(SAML_SERVER_URL, 'saml2/ls/'),
saml2.BINDING_HTTP_REDIRECT),
(path.join(SAML_SERVER_URL, 'saml2/ls/post/'),
saml2.BINDING_HTTP_POST),
],
},
},
},
# where the remote metadata is stored, local, remote or mdq server.
# One metadatastore or many ...
'metadata': {
'local': [path.join(BASEDIR, 'idp_metadata.xml')]
},
# Signing
'key_file': path.join(BASEDIR, 'samlkey.key'), # private part
'cert_file': path.join(BASEDIR, 'samlcert.pem'), # public part
# own metadata settings
'contact_person': [
{'given_name': '--',
'company': '--',
'email_address': '--',
'contact_type': '--'}
],
# you can set multilanguage information here
'organization': {
'name': [('--', 'en')],
'display_name': [('--', 'en')],
'url': [('--', 'en')],
},
"valid_for": 24
}
My middleware is as follows:
MIDDLEWARE = [
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.security.SecurityMiddleware',
'user_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',
'app.middleware.APPMiddleware',
'djangosaml2.middleware.SamlSessionMiddleware'
]
With the above mentioned settings I am facing a couple of issues
After successfully authenticating from my SSO server by the time the request reaches my /login Url both the request.session and request.saml_session variables are getting reset and I am getting a complete new session ID. And also I am missing the saml_session attributes due to this issue. I did add a debug point in the djangosaml2 views and in there just before returning the response I could see the attributes present. But for some reason by the time the request reaches my app, its getting reset.
When I try to logout on saml2/logout, I am seeing the following error:
'NoneType' object has no attribute 'name_qualifier'
I cant seem to find what I am missing here. I have tried all I could think of but stuck. Any help is greatly appreciated. Thanks in advance.
I ended up doing the following two things, then it started working for me
Downgraded the djangosaml2 and pysaml version to 0.19.0 and 4.9.0 respectively.
For HTTPS connection, added SESSION_COOKIE_SECURE = True and for dev i.e. run server cases, SESSION_COOKIE_SECURE = False in your settings.py
I was migrating Django from 1.1 to 3.1. Your codebase actually fixed my issue. I added the SESSION_SERIALIZER in my saml/config.py:
SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'
And added SamlSessionMiddleware in settings.py:
djangosaml2.middleware.SamlSessionMiddleware
My issue was:
'WSGIRequest' object has no attribute 'saml session'

Generate a JWT token in django for authentication between different service

My use case is to create a JTW token ( probability from Django Admin ) and use that token from other services ( clients, postman, microservice, etc ). That token should not expire because if it expires than I have to create a new Token and configure all the services again with the new Token. I am aware that 'rest_framework.authtoken' exists but it has some drawbacks -
It doesn't create JWT token
I Can see it in Django Admin after creation, ( I want to surface token only at the time of creation )
I want to have a service similar to most of the sms/email providers have. They provide us an API key and we can use that for future API calls. Looking forward to a solution. Thanks.
DRF has an inbuilt package for JWT authentication all you need is to use that with modulations into JWT KEYS in your settings.py and add jwt authentication to your default authentication classes: (I ADDED A CUSTOM PAYLOAD BUT U CAN ADD THE DEFAULT ONE TOO)
SETTINGS.PY:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'corsheaders',
'rest_framework',
'rest_framework.authtoken'
]
REST_FRAMEWORK = {
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
'rest_framework_jwt.authentication.JSONWebTokenAuthentication',
),
}
JWT_AUTH = {
'JWT_ENCODE_HANDLER':
'rest_framework_jwt.utils.jwt_encode_handler',
'JWT_DECODE_HANDLER':
'rest_framework_jwt.utils.jwt_decode_handler',
'JWT_PAYLOAD_HANDLER':
'rest_framework_jwt.utils.jwt_payload_handler',
'JWT_PAYLOAD_GET_USER_ID_HANDLER':
'rest_framework_jwt.utils.jwt_get_user_id_from_payload_handler',
'JWT_RESPONSE_PAYLOAD_HANDLER':
'rest_framework_jwt.utils.jwt_response_payload_handler',
'JWT_ALLOW_REFRESH': False,
'JWT_REFRESH_EXPIRATION_DELTA': datetime.timedelta(days=365),
'JWT_SECRET_KEY': SECRET_KEY,
# settings for the start of the autorization header
'JWT_AUTH_HEADER_PREFIX': 'JWT',
# Authorization : JWT <token>
'JWT_AUTH_COOKIE': "JwtToken",
}
URLS.PY :(ADD THE FOLLOWING)
from rest_framework_jwt.views import verify_jwt_token
urlpatterns = [
....
path('api/jwt-verify/', verify_jwt_token),
....
]
VIEWS.PY (CREATE THE TOKEN and verify):
##import the below two##
from rest_framework_jwt.utils import jwt_payload_handler
from rest_framework_jwt.utils import jwt_encode_handler
from rest_framework_jwt.utils import jwt_response_payload_handler
##if the requested user is active and authenticated
####user = authenticate(username=username, password=password) is NOT None
if user.is_active:
user_obj = User.objects.get(
username__iexact=username)
payload = jwt_payload_handler(user_obj)
token = jwt_encode_handler(payload)
response_payload = jwt_response_payload_handler(
token, user_obj, request=request)
response = requests.post("http://127.0.0.1:8080/api/jwt-verify/",
{"token": token})
return JsonResponse({'msg': "token is verified", 'token': response_payload['token']}, safe=False, status=response.status_code)
I found https://florimondmanca.github.io/djangorestframework-api-key/ and it fulfills all my requirements. From docs
Django REST Framework API Key is a powerful library for allowing server-side clients to safely use your API. These clients are typically third-party backends and services (i.e. machines) which do not have a user account but still need to interact with your API in a secure way.
✌️ Simple to use: create, view and revoke API keys via the admin site, or use built-in helpers to create API keys programmatically.
🔒 As secure as possible: API keys are treated with the same level of care than user passwords. They are hashed using the default password hasher before being stored in the database, and only visible at creation.
🎨 Customizable: satisfy specific business requirements by building your own customized API key models, permission classes and admin panels
I am using this package now in my project.

django-rest-auth google and facebook sign up returning access token and code

I am building a rest api with Django, and I an using Django rest auth for social authentication. I believe I am doing everything right. upon visiting the route I get a response that I am to provide both access token and code for both Google and Facebook. I am lost at this point what to do. Please anyone who has an idea, please share.
I have gotten the secret key and client id from both providers and inputed them in my settings.py and django admin.
settings.py
INSTALLED_APPS = [
...
'django.contrib.sites',
...
'rest_auth',
'rest_auth.registration',
'allauth',
'allauth.account',
'allauth.socialaccount',
'allauth.socialaccount.providers.google',
'allauth.socialaccount.providers.facebook',
...
]
SOCIALACCOUNT_PROVIDERS = {
'facebook': {
'METHOD': 'oauth2',
'SCOPE': ['email', 'public_profile', 'user_friends'],
'AUTH_PARAMS': {'auth_type': 'reauthenticate'},
'INIT_PARAMS': {'cookie': True},
'FIELDS': [
'id',
'email',
'name',
'first_name',
'last_name',
'verified',
'locale',
'timezone',
'link',
'gender',
'updated_time',
],
'EXCHANGE_TOKEN': True,
'LOCALE_FUNC': 'path.to.callable',
'VERIFIED_EMAIL': True,
'VERSION': 'v2.12',
'APP': {
# get the key from "https://developers.facebook.com/apps/615248019004301/settings/basic/"
'client_id': 'code',
'secret': 'code',
'key': ''
}
},
'google': {
'SCOPE': [
'profile',
'email',
],
'AUTH_PARAMS': {
'access_type': 'offline',
},
'APP': {
# get from "console.developers.google.com/" then apis then credentials then oauthclient
# fill in http://127.0.0.1:8000/accounts/google/login/callback/ in the “Authorized redirect URI” field
'client_id': 'code.apps.googleusercontent.com',
'secret': 'code',
'key': ''
}
}
}
SITE_ID = 1
SOCIALACCOUNT_ADAPTER = "allauth.socialaccount.adapter.DefaultSocialAccountAdapter"
SOCIALACCOUNT_EMAIL_REQUIRED = ACCOUNT_EMAIL_REQUIRED
OK I'm in a similar situation and have been doing a lot of reading. Looks like you have performed all the setup correctly. And now you are trying to perform signup / login via your API from a client.
I'm going to make some assumptions as you don't provide a lot in your question by way of detail. For instance, I'm not sure what route you are visiting, or, what kind of an API client (DRF browseable API, React frontend, mobile app?) you are using. That said, it shouldn't really matter what kind of client you use, the process should be the same.
Here are the steps:
You will need to initiate signup / login from your API client either by rolling your own code or using whatever libraries are available for the technology you are using. For instance, Facebook provides its own JavaScript SDK. If you are using React, you could use react-facebook-login. Note that I've personally used neither so YMMV.
On successful authentication, at Facebook for instance, you will get a accessToken, which your client should send to your API at /rest-auth/facebook/ (or whatever you have configured in your urls.py).
When this flow happens, a new user should be created in your backend with all their details.
Here is an example blog post that I found where the author shows this flow for a React frontend application: https://medium.com/#pratique/social-login-with-react-and-django-ii-39b8aa20cd27.
Here is another example of a similar flow I found on SO. In the answer, the user is using the python-social-auth package instead of django-allauth but the flow is similar: https://stackoverflow.com/a/46476631/399435.
Since your client will be making requests to your API, I believe that you will also have to setup CORS correctly for such requests to succeed.
Hope that points you in the right direction. I'm going to be attempting this myself soon and if I learn that something is different, I will get back to edit this answer.
As far as I understand, the problem it's that are you sending a GET request, when the login view only accept a POST request. You must change the method.

django-debug-toolbar won't display from production server

I'd like to view the Django Debug Toolbar when accessing my production website which is running Django 1.6. My server is running Debian 7.8, Nginx 1.2.1, and Gunicorn 19.1.1. However, when I try to access the site after adding DDT to my installed apps, I get the following error:
NoReverseMatch at /
u'djdt' is not a registered namespace
Exception Location: /home/mysite/venv/mysite/local/lib/python2.7/site-packages/django/core/urlresolvers.py in reverse, line 505
Error during template rendering
In template /home/mysite/venv/mysite/local/lib/python2.7/site-packages/debug_toolbar/templates/debug_toolbar/base.html, error at line 12
data-store-id="{{ toolbar.store_id }}" data-render-panel-url="{% url 'djdt:render_panel' %}"
I know it's not recommended that you run the toolbar in production but I just want to run it while I do some testing on my production server prior to opening it up for public use. As you might expect, it works just fine in my development environment on my laptop. I did some research and have ensured that I'm using the "explicit" setup as recommended here. I also ran the command "django-admin.py collectstatic" to ensure the toolbar's static files were collected into my STATIC_ROOT.
Since I'm running behind a proxy server, I also added some middleware to ensure that the client's IP address is being passed to the toolbar's middleware instead of my proxy's IP address. That didn't fix the problem either.
I'm showing all the settings which seem pertinent to this problem below. Is there something else I'm missing?
Thanks!
These are the pertinent base settings:
SETTINGS_ROOT = os.path.abspath(os.path.dirname(__file__).decode('utf-8'))
STATIC_ROOT = '/var/www/mysite/static/'
STATIC_URL = '/static/'
STATICFILES_DIRS = (
os.path.join(SETTINGS_ROOT, "../../static"),
)
STATICFILES_FINDERS = (
'django.contrib.staticfiles.finders.FileSystemFinder',
'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)
TEMPLATE_LOADERS = (
'django.template.loaders.filesystem.Loader',
'django.template.loaders.app_directories.Loader',
)
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.middleware.common.BrokenLinkEmailsMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
TEMPLATE_DIRS = (
os.path.join(SETTINGS_ROOT, "../../templates"),
)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
# Django management commands in 'scripts'
'scripts',
'apps.account',
)
These production-only settings get added to base settings in production:
DEBUG = True # DDT needs this to be True
TEMPLATE_DEBUG = DEBUG
INSTALLED_APPS += (
'django_extensions',
# I'm using Django 1.6
'debug_toolbar',
)
if 'debug_toolbar' in INSTALLED_APPS:
MIDDLEWARE_CLASSES += ('conf.middleware.DjangoDebugToolbarFix',
'debug_toolbar.middleware.DebugToolbarMiddleware', )
# I had to add this next setting after upgrading my OS to Mavericks
DEBUG_TOOLBAR_PATCH_SETTINGS = False
# IP for laptop and external IP needed by DDT
INTERNAL_IPS = ('76.123.67.152', )
DEBUG_TOOLBAR_CONFIG = {
'DISABLE_PANELS': [
'debug_toolbar.panels.redirects.RedirectsPanel',
],
'SHOW_TEMPLATE_CONTEXT': True,
'INTERCEPT_REDIRECTS': False
}
This is in my urls.py:
if 'debug_toolbar' in dev.INSTALLED_APPS:
import debug_toolbar
urlpatterns += patterns('',
url(r'^__debug__/', include(debug_toolbar.urls)),
)
Here is the additional middleware:
class DjangoDebugToolbarFix(object):
"""Sets 'REMOTE_ADDR' based on 'HTTP_X_FORWARDED_FOR', if the latter is
set."""
def process_request(self, request):
if 'HTTP_X_FORWARDED_FOR' in request.META:
ip = request.META['HTTP_X_FORWARDED_FOR'].split(",")[0].strip()
request.META['REMOTE_ADDR'] = ip
I am using the exact same setup as OP describes, with the noticeable exception of running everything in a separate Docker container which make the IP of each service hard to predict.
This is how you force Django Debug Toolbar to always show (only use this locally, never in production):
def custom_show_toolbar(request):
return True # Always show toolbar, for example purposes only.
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': custom_show_toolbar,
}
Actually, you shouldn't set DEBUG to True on your production server, keep it False and check my solution below:
The default DDT callback (debug_toolbar.middleware.show_toolbar) checks are that DEBUG must be set to True, the IP of the request must be in INTERNAL_IPS, and the request must not be an AJAX request.
We can provide our own callback which excludes the DEBUG setting condition:
settings:
INTERNAL_IPS = ['YOUR.IP.ADDRESS.HERE'] # put your client IP address here (not server IP!)
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': lambda request: not request.is_ajax() and request.META.get('REMOTE_ADDR', None) in INTERNAL_IPS
}
You can check HTTP_X_FORWARDED_FOR if you wish too, it is up to you.
urls:
if 'debug_toolbar' in settings.INSTALLED_APPS:
import debug_toolbar
urlpatterns += [
url(r'^__debug__/', include(debug_toolbar.urls)),
]
If you are on docker the following code helped me get the internal ip.
# Debug Toolbar
if DEBUG:
import os
import socket
hostname, _, ips = socket.gethostbyname_ex(socket.gethostname())
INTERNAL_IPS = [ip[:-1] + '1' for ip in ips] + ['127.0.0.1', '10.0.2.2', ]
credit goes here https://gist.github.com/douglasmiranda/9de51aaba14543851ca3#file-option2-py
And this answer has additional options: https://stackoverflow.com/a/49818040/317346
So django-debug-toolbar uses JavaScript to run as well. have you confirmed you have n conflicting JS scripts affecting your setup? I had a hell of a time with one project using DjDT and it was a back-to-top script that was interfering...
Also, I know you have lots of extra code to handle your proxy situation, but have you uan it straight out of the box to see if that works on your server? I might create a new virtualenv, start from scratch and make sure it works on your server and then proceed to add apps and additional configuration.
These are probably thing you have thought of but I thought I'd add them anyway since your question hasn't received much action.
Good luck.
I had to add the following to the project url.py file to fix the issue. After that debug tool bar is displayed.
from django.conf.urls import include
from django.conf.urls import patterns
from django.conf import settings
if settings.DEBUG:
import debug_toolbar
urlpatterns += patterns('',
url(r'^__debug__/', include(debug_toolbar.urls)),
)

django-axes lockout not working

Has anyone here successfully configured django-axes? Axes is a module which provides you with the ability to lock out a user after a specified number of unsuccessful login attempts. I'm having three problems which I haven't been able to solve. First, my application continues to allow me to try to login even if I've exceeded the failure limit, second my site isn't displaying the lockout template if I exceed the failure limit, and third my administrative site isn't showing any login failures. I've read the docs on Github but I still don't see what I'm doing wrong. My files are shown below. Thanks for your help.
# Relevant settings in settings.py
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'login',
'axes',
)
# MIDDLEWARE_CLASSES contains usual classes
MIDDLEWARE_CLASSES += (
'axes.middleware.FailedLoginMiddleware',
)
AXES_LOGIN_FAILURE_LIMIT = 1
import datetime as dt
delta = dt.timedelta(minutes=1)
AXES_COOLOFF_TIME = delta
AXES_LOCKOUT_URL = '/accounts/locked_out/'
AXES_LOCKOUT_TEMPLATE = 'registration/locked_out.html'
# Relevant routes in urls.py
urlpatterns = patterns('',
# This is my login view, nothing special there
url(r'^$', 'login.views.firewall_login'),
# The view for Axes lockout
url(r'^accounts/locked_out/$',
'login.views.locked_out',
{'template': 'registration/locked_out.html'}),
url(r'^admin/', include(admin.site.urls)),
)
# views.py
def locked_out(request, template):
"""User is redirected here after they're locked out."""
return render(request, template)
Add this to your setting.py:
AUTHENTICATION_BACKENDS = [
# AxesBackend should be the first backend in the AUTHENTICATION_BACKENDS list.
'axes.backends.AxesBackend',
# Django ModelBackend is the default authentication backend.
'django.contrib.auth.backends.ModelBackend',
]
All I can help with is that you need to add
AXES_ENABLE_ACCESS_FAILURE_LOG = True # log access failures to the database.
Not sure about the other questions myself, unfortunately