In Django 1.5, I would like to create a custom user by subclassing AbstractUser. However I can't figure out how to do this and diable sessions at the same time, as Django seems to have a mess of dependencies. Note: I have tried removing 'django.contrib.sessions.middleware.SessionMiddleware' from the MIDDLEWARE_CLASSES tuple in settings.py.
Any ideas would be appreciated.
Take a look at how this guy disables sessions for some requests by using middleware: Disable session creation in Django
You could use that, but for all requests instead.
Related
I am building a django server for an API that relies on JWT (or Token based - https://www.django-rest-framework.org/api-guide/authentication/#tokenauthentication) authentication for our users.
I don't need session based authentication for any purpose. It creates an unnecessary query on each request, and also authenticates users when I don't want to authenticate them (I want browsers to only authenticate when it includes an Authentication header in the request, and stay AnnonymousUser otherwise. This is because it creates issues in some of my middlewares where I verify if I am dealing with a guest or a authenticated user).
However, the issue comes when I try to use the admin application as well (I can't imagine building this app without the use of the django admin page). When I remove the session-related middlewares:(django.contrib.sessions.middleware.SessionMiddleware, django.contrib.auth.middleware.AuthenticationMiddleware and django.contrib.messages.middleware.MessageMiddleware) from my settings file, I get the following error when I do a runserver:
ERRORS:
?: (admin.E408) 'django.contrib.auth.middleware.AuthenticationMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E409) 'django.contrib.messages.middleware.MessageMiddleware' must be in MIDDLEWARE in order to use the admin application.
?: (admin.E410) 'django.contrib.sessions.middleware.SessionMiddleware' must be in MIDDLEWARE in order to use the admin application.
Can someone think of a workaround where I can disable sessions in Django, while also being able to use the admin panel? One solution I thought of is to hack up adding the authorization header to each admin page request, but 1) I have no idea how to proceed with this idea and 2) (more importantly), I cannot do a runserver while disabling the session middlewares.
I'd like to upgrade an existing application to a more recent version of django. In 1.4 they changed the password hashing algorithm such that all my old passwords will no longer match when people try to login. Is there some way to upgrade but not require users to reset their passwords?
according to https://docs.djangoproject.com/en/dev/topics/auth/passwords/#auth-password-storage it will still check everything as usual.
if you are worried about storing everything as SHA1 by default, then put the hasher first in the list (this is not recommended though).
# settings.py
PASSWORD_HASHERS = (
'django.contrib.auth.hashers.SHA1PasswordHasher',
'django.contrib.auth.hashers.PBKDF2PasswordHasher',
...
)
if you need to check for yourself, you can consider using virtualenv with the newer django==1.5 package and create a dummy project/app connected to the same database to try it out. If you have admin privileges and already use the admin interface, you can use that to login there.
I did the same upgrade last month and Django passwords still fully functional. The changes I made are basically in generic views( now all generic views are class based) , The logging in settings.py was changed and I have to put a ALLOWED_HOSTS list. For example: ALLOWED_HOSTS = ['.stackoverflow.com']
Particularly, I changed my urls calls cause I was using named urls without quotes in url tags and it's no longed supported by django. The right way is like this: {% url 'name_of_the_view' arg1 arg2%}
I suggest you to create another environment and try use django 1.5 just making this small changes.
Because I'm using my own authentication and authorization system (with my own User/Permission model), I would like to completely disable this standard app from Django.
I've tried removing the relevant lines from MIDDLEWARE_CLASSES and
INSTALLED_APPS, but when I use the syncdb command, the default tables
that come with the default authentication system are still being
created. Is there a way to prevent this from happening? My main problem is that the standard tables are overriding the tables that I want to use for my own auth system.
INSTALLED_APPS = (
'django.contrib.sessions',
'form_utils',
'org',
'auth',
'entities',
)
I have also tried prepending the apps with the project package, this had no effect.
Is there maybe another setting that I'm overlooking? Other possible
variables that could cause these standard apps to be enabled despite
my efforts?
I also don't use the built-in admin system, so I don't think that
could be a problem.
Additional information: I have recently upgraded Django 1.2 to 1.3. Could this be the cause of my problem?
Edit: Apparently, this issue is caused by a change in Django 1.3. The related ticket is here: http://code.djangoproject.com/ticket/15735
Any hints?
I believe that the authentication module is being pulled in by RequestContext.
By default, the setting TEMPLATE_CONTEXT_PROCESSORS includes django.contrib.auth.context_processors.auth.
I didn't have the issue of django creating the auth database tables, but it was inserting an AnonymousUser object into my context and my session under the 'user' key, even though I'd removed the auth modules from my INSTALLED_APPS and MIDDLEWARE_CLASSES settings.
I removed that item from TEMPLATE_CONTEXT_PROCESSORS and things started working the way I had been expecting.
The upgrade from 1.2 to 1.3 in your case might have meant you started using class-based generic views (which are awesome), or perhaps you otherwise started using RequestContext instead of ordinary context dicts. Either way, it seems that when auth is given as a context processor, django behaves as though auth were in your installed apps, whether you actually wanted it there or not.
I hope this is of assistance.
Hay all, I've been reading up on middleware and how to use it with a context object. I want to write a simple middleware class which i can use on my own applications, it will essentially be a cut down version of the django one.
The problem i seem to have is that if i have
INSTALLED_APPS = ('django.contrib.my_auth')
in the settings file, all is well. I've also added
MIDDLEWARE_CLASSES = ('django.contrib.my_auth.middleware.MyAuthMiddleware')
in it and everything is fine.
My question is, how would i make my middleware automatically generate tables from a models.py module, much like how the django auth does when i run manage.py syncdb?
thanks
Django auth middleware doesn't generate any tables. Django does it looking through INSTALLED_APPS when you run manage.py syncdb. Therefore all should already be fine.
I'm new to Django and in bouncing around the framework over the past few days I haven't been able to figure out how to properly install the django.contrib.auth app in my project.
Well, installing is probably not the right word, but configuring it for my purposes.
What I'm truly hoping to do is extend the built-in classes to simply create registration and login forms, since my User class is working just fine from terminal.
In settings.py I have django.contrib.auth in my INSTALLED_APPS.
I also have installed the Authentication Middleware and Sessions Middleware.
I can also clearly see in Django.contrib.auth.views and Django.contrib.auth.forms where the registration and authentication handlers are.
My problem, it seems, since I'm new to the framework, is properly including these files in my project and generating the HTML forms for registration and login.
(As in, do I need to include these Auth files in my app's forms.py? What do I need to model that hasn't already been modeled for me? And finally, since I can see in Django.contrib.auth.views a need for a registration directory with HTML templates, how can I get these all communicating with each other properly?)
Figured out the problem. Just needed to follow Django's URL Conf conventions. Example: (r'^accounts/login/$', 'django.contrib.auth.views.login'),
James Bennet's django-registration is an excellent helper application used for a common registration / login pattern.