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.
Related
I know this might sound stupid but I was just wondering what's the difference if I just type 'myapp' instead of 'myapp.apps.myappConfig' in my Installed Apps list. Is it something related to models or what?
Regards
If you use myapp.apps.myappConfig, then you are explicitly telling Django to use that app config class.
Changing the app config class lets you change the behaviour of the application, for example, when you use the admin app, you can use django.contrib.admin.apps.AdminConfig which autodiscovers apps, or django.contrib.admin.apps.SimpleAdminConfig, which does not.
If you just use myapp, then Django will try to use default_app_config. If that isn't set, then it will use the default AppConfig.
A lot of the time, there isn't any customisation in myappConfig, or default_app_config is set, so you'll get the same behaviour whichever style you use in INSTALLED_APPS.
Ever since AppConfig was added in Django 1.7, the recommendation has been to use ``myapp.apps.myappConfigbecause it's explicit, and avoid usingdefault_app_config`.
However, in practice, it seems that users have preferred the simplicity of using myapp. Therefore, there's an open pull request which will remove default_app_config, and automatically select the app config class when there is only one.
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.
I've been working on a Django-Mongodb application. I was trying to use django-registration module in my project, but never got it to work.
https://github.com/lig/django-registration-me
Have anyone used django-registration in their django-nonrel? If you do, can you point me some instructions? What should User model look like since it is in django-nonrel?
Thanks in advance,
Since nobody really answered it, and I figured it out. I will just answer my own question as the reference for others who might be having the same problem.
I found it easier to use Mongoengine Authentication backend on top of Django authentication. Use the following in settings.py.
AUTHENTICATION_BACKENDS = (
'mongoengine.django.auth.MongoEngineBackend',
)
SESSION_ENGINE = 'mongoengine.django.sessions'
https://mongoengine-odm.readthedocs.org/en/latest/django.html
Apart from that you use pretty much the same code as in regular django, and a bit different at accessing the user from request. Just need to:
from mongoengine.django.auth import User
And if you use form in django, you probably end up using form for mongodb instead.
https://github.com/jschrewe/django-mongodbforms
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.
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.