8

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?

Sander
  • 83
  • 1
  • 4
  • 1
    did you drop tables before ./manage.py syncdb? – dting Apr 01 '11 at 07:53
  • I did, I even dropped the entire database for testing purposes. It just keeps creating the default auth_user table (while I want to use my own). – Sander Apr 01 '11 at 08:57

2 Answers2

7

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.

Brendan Jurd
  • 86
  • 1
  • 2
  • My apologies for accepting an answer so late, but thank you nonetheless :) – Sander Jul 05 '12 at 15:59
  • I wanted to remove Auth app as well, and after removing the middlewares I was still getting the error. Removed the entry from the template preprocessor in setting and everything runs smoothly now! – Makers_F Dec 14 '15 at 11:08
  • Is there any update for customizing the auth app now in a different way? – Ishika Jain Jul 12 '21 at 05:33
1

If you are using DRF, you will still have this problem.

Add These lines in your settings.py and it will solve the problem

REST_FRAMEWORK = {
    /*

    */
    'UNAUTHENTICATED_USER': None, # Needed once you disable django.contrib.auth
}

The problem is that the default value for UNAUTHENTICATED_USER is AnonymousUser (from contrib.auth). So if you don't set that setting to something else because you don't care to provide your own (likely, if you don't use auth) you will get this warning.

Md Abu Saif
  • 429
  • 2
  • 5