Home/ Questions/Q 6807527
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T19:50:35+00:00

Because I’m using my own authentication and authorization system (with my own User/Permission model),

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0