Removing django.contrib.auth app

[mkohram]

Is there any way to remove the django.contrib.auth app if I don't need authentication. The six tables it creates in my database are pretty ugly. Here is my config:

INSTALLED_APPS = (
#    'django.contrib.admin',
#    'django.contrib.auth',
    'django.contrib.contenttypes',
#    'django.contrib.sessions',
#    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',
    'core'
)

MIDDLEWARE_CLASSES = (
#    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
#    'django.contrib.auth.middleware.AuthenticationMiddleware',
#    'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
#    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    'django.middleware.security.SecurityMiddleware',
)

REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES' : [],
    'DEFAULT_PERMISSION_CLASSES' : [],
    'PAGINATE_BY': 1000
}

I get deprecation warnings:

(env)... $ ./manage.py runserver
Performing system checks...

System check identified no issues (0 silenced).
August 11, 2015 - 16:05:48
Django version 1.8.3, using settings '...'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
/Users/.../env/lib/python3.4/site-packages/django/contrib/auth/models.py:41: RemovedInDjango19Warning: Model class django.contrib.auth.models.Permission doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Permission(models.Model):

/Users/.../env/lib/python3.4/site-packages/django/contrib/auth/models.py:98: RemovedInDjango19Warning: Model class django.contrib.auth.models.Group doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class Group(models.Model):

/Users/.../env/lib/python3.4/site-packages/django/contrib/auth/models.py:436: RemovedInDjango19Warning: Model class django.contrib.auth.models.User doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. This will no longer be supported in Django 1.9.
  class User(AbstractUser):

[lovelydinosaur]

Is there any way to remove the django.contrib.auth app if I don't need authentication.

Yes, you're completely free to remove it.

I get deprecation warnings:

It looks like you're most likely importing from django or rest_framework before the settings are loaded. This is a Django usage issue (and possibly scope for improvement in Django core - unsure?) but nothing to do with REST framework.

[ivanvenosdel]

@tomchristie @mkohram We ran into this as well when using DRF without doing authorization. It's not technically a DRF bug but there is some behaviour that makes it a huge gotcha.

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.

So for the record, if your API does not use authentication make sure that this is in your DRF settings:
'UNAUTHENTICATED_USER': None

[xordoquy]

@ivanvenosdel I don't think using AnonymousUser is an issue. It's provided by Django but doesn't require any table to be loaded, does it ?
Those warnings can be safely ignored as long as you don't use the mentioned classes.

[ivanvenosdel]

@xordoquy You are correct, it doesn't require a table to be loaded. There are no functional problems at the present time.

Those warnings can be safely ignored as long as you don't use the mentioned classes.

We hope so but the fact that it's a deprecation warning makes us concerned that something in 1.9 will make it more than a warning. Also since the Django error is not able to determine what app usage is producing the behaviour it makes it something we would prefer to fix now instead of in the middle of an upgrade.

Otherwise I guess if you are certain that referencing it won't become a problem in 1.9 maybe the false alarm is a bug in Django core? Though I am not sure how they could possibly distinguish a reference from usage. We are at the latest 1.8 release.

[lovelydinosaur]

Otherwise I guess if you are certain that referencing it won't become a problem in 1.9 maybe the false alarm is a bug in Django core?

Well, 1.9 alpha has been released so this is readily testable ATM. Would happily accept an issue for it if there is a demonstrable problem.

[ivanvenosdel]

@tomchristie Good point, here is what I get with 1.9a1 (Note: For us this is when loading a DRF URL not when running the server):

Exception Type:     RuntimeError
Exception Value:    
Model class django.contrib.contenttypes.models.ContentType doesn't declare an explicit app_label and either isn't in an application in INSTALLED_APPS or else was imported before its application was loaded. 

So it looks like it does turn into an explicit failure. If I put in the 'UNAUTHENTICATED_USER': None setting I mentioned above it goes away.

[ivanvenosdel]

Submitted issue as #3494

[mkohram]

@ivanvenosdel Thanks for clearing this up.