i'm trying to find bug for few hours now but nothing comes out.
Django gives me this error message when i'm trying to access request.SESSION from view. No other errors.
'WSGIRequest' object has no attribute 'SESSION'
Here is my Django settings what points to sessions and authentication. Most of them are set to their defaults.
AUTHENTICATION_BACKENDS = ('django.contrib.auth.backends.ModelBackend',)
AUTH_PROFILE_MODULE = 'alkimikis.users.models.UserProfile'
INSTALLED_APPS = ['django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.auth', 'django.contrib.admin', 'alkimikis.users']
MIDDLEWARE_CLASSES = ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware')
SESSION_ENGINE = 'django.contrib.sessions.backends.db'
Ideas for solution or deeper debugging? Anyone?
It's request.session. Lower case.
To debug, use the unit test framework. You can then add print statements and see the results.
print request
Very helpful.
Related
I have a dockerized Django app that utilizes Gunicorn and Nginx. When logging in on the admin page using localhost, no CSRF error emerges. When running the docker on Amazon EC2 with Route 53 as the proxy server (https redirects to http), I get the CSRF error on login. I note the following in my settings.py file (I added the SECURE_SSL_REDIRECT = False but it has had no effect):
ALLOWED_HOSTS = ['localhost', '.website_name.ca']
SECURE_SSL_REDIRECT = False
# Application definition
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'The6ixDjango.apps.The6IxdjangoConfig',
]
MIDDLEWARE = [
'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',
]
Given that I have Route 53 on the front-end, is it 'safe' to remove the csrf middleware reference in the MIDDLEWARE list?
Since you're using a proxy that translates https requests into http, you need to configure Django to allow POST requests from a different scheme (since Django 4.0) by adding this to settings.py:
CSRF_TRUSTED_ORIGINS = ["https://yourdomain.com", "https://www.yourdomain.com"]
If this does not solve your problem, you can temporarily set DEBUG = True in production and try again. On the error page, you will see a "Reason given for failure" that you can post here. (You write about "the CSRF error on login" but there are 9 possible errors, it would be useful to know the actual error.)
SECURE_SSL_REDIRECT should be False indeed (since Route 53 will handle the redirect for you) but False is the default value so you can simply omit the SECURE_SSL_REDIRECT setting.
It is definitely not safe to remove CsrfViewMiddleware from the MIDDLEWARE list. Route 53 will not give you an equivalent protection against CSRF-attacks.
I'm having a problem with the csrf token on a Django powered site, which I'm close to reporting as a bug.
Problem is basically, CSRF token fails when DEBUG is False. When DEBUG is False, if I'm using sessions for the csrf token (Django 1.11):
CSRF_USE_SESSIONS = True
CSRF_COOKIE_AGE = None
...all forms/post requests on the frontend fail authentication, but I can login fine to the Django admin panel, e.g., csrf token authentication succeeds.
On the other hand, if I'm using cookies for csrf, authentication on the frontend for forms/post requests go through without any problem, but then it fails for the admin login: CSRF verification failed. Request aborted.
Part of my settings.py file looks like this:
SECRET_KEY = os.getenv('DJANGO_SECRET_KEY')
DEBUG = 'DEBUG' in os.environ
# CSRF
# These are commented/uncommented depending on what method I'm testing
# CSRF_USE_SESSIONS = True
# CSRF_COOKIE_AGE = None
# I added the cookie domain setting after I started seeing the problem
# and hoped it would have resolved it; it didn't help.
CSRF_COOKIE_DOMAIN = '.{0}'.format(os.getenv('DOMAIN_NAME', 'mysite.com'))
ALLOWED_HOSTS = [
'.mysite.com',
'.mysite.info',
]
if DEBUG:
ALLOWED_HOSTS.extend(['.mysite.dev'])
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'mainsite',
'constance',
'jstemplate',
'compressor',
]
MIDDLEWARE = [
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.security.SecurityMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
'mainsite.middleware.Guid',
'mainsite.middleware.SiteLang',
]
If I set DEBUG to True, I have no issues whatsoever with CSRF token authentication, both on the frontend as with logging into the Django admin panel.
I'm also using Redis as a cache. Am I missing something crucial that is causing this CSRF error? I must point out, there was a point in which I was not getting this error, but I cannot for the life of me pinpoint what change would have created this behavior with the CSRF token.
I also have the same issue.
I solve this by
1. pip install django-sslserver.
2. Put sslserver in the INSTALLED_APPS.
3. python manage.py runsslserver
In accordance with the django-pipeline docs, I've added 'pipeline.middleware.MinifyHTMLMiddleware', to my MIDDLEWARE_CLASSES to minify html files. But, when I check the htmls that have been rendered while running the server, they are not minified. Can some one please suggest if I am missing anything.
Below are my MIDDLEWARE_CLASSES. I even tried with GZipMiddleware class enabled, but it still does'nt work. I have also tried with both DEBUG = False & DEBUG = True in settings.py with no success.
MIDDLEWARE_CLASSES = (
#'django.middleware.gzip.GZipMiddleware',
'pipeline.middleware.MinifyHTMLMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'Testapp.signin.views.SocialAuthExceptionMiddleware',
)
EDIT: Added Installed Apps and Static files storage settings.
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.messages',
'django.contrib.staticfiles',
#'django.contrib.admin',
'social.apps.django_app.default',
# 'django.contrib.admindocs',
'Testapp',
'signin',
'pipeline',
)
STATICFILES_STORAGE = 'pipeline.storage.PipelineCachedStorage'
To work pipeline MinifyHTMLMiddleware change DEBUG = False in settings.py
DEBUG = false
Or add in settings.py
PIPELINE_ENABLED = True
i've had the same issue, but I've found the solution. You have to add this Middleware class first:
'htmlmin.middleware.MarkRequestMiddleware',
When you do that it adds to request an attribute
request._hit_htmlmin = True
which is checked then in MinifyHTMLMiddleware class. Now it's working great.
I'm experiencing an issue with Django and Django Auth. From time to time the login page will not allow users to login. When the user presses login (on the /admin login form OR any custom login form) the page simply refreshes. After debugging further it seems that it is creating a session and then expiring it (somehow). Has anyone experienced this type of behavior with Django Auth?
Thanks,
cory
I haven't had this problem.
But so, you should check your apps, middleware, and context processor specifications in your settings.py file. You'll want to be sure the following are in place (in addition to whatever else you need for your specific app):
MIDDLEWARE_CLASSES = (
# ...
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
# ...
)
TEMPLATE_CONTEXT_PROCESSORS = (
# ...
"django.core.context_processors.auth",
"django.core.context_processors.request",
# ...
)
INSTALLED_APPS = (
# ...
'django.contrib.auth',
'django.contrib.sessions',
'django.contrib.sites',
# ...
)
... make sure that's all good to go and see if your problem persists. Good luck.
My flatpages relevant options in the settings.py look like this:
MIDDLEWARE_CLASSES = (
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
)
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.admin',
'django.contrib.flatpages',
'django.contrib.humanize',
'registration',
)
and in the Backend I added a flatpage with the url set to "/" and one with "/about/. When I call these pages, django shows a 404 error. All my flatpages have a unique template. The "Template Name" entries are looking like this: /flatpages/about.html. What did i miss?
I found it.
I forgot to set the SITE_ID in settings.py correctly.
Do you have a base/default template in place for your flatpages, too? It's easy to miss as they docs don't go into much detail.
Easiest fix is to add /flatpages/default.html to your known templates, basing default.html on the example in the docs.
Or you can point your flatpages to a specific, existing template with the additional options in the admin edit page for a flatpage.
The key statement is changing the SITE_ID in settings.py which
has nothing to do with flatpages - it is a problem that new users
run into when launching into the 'admin' and adding (say) '127..0.0.1' to
the sites menu ( an addition to the default 'example.com' )
In trying to get everything else right, it is easy to overlook
making SITE_ID = 2.
Make 'locahost' the default - get rid of the default tripwire.
Glad I came across this!
Bob