Skip to main content

Build Status Coverage Status Version

Overview

Provides a polymorphic parent User model and several child models.

You can enable and disable child models without affecting foreign keys to the the parent model, and avoid complicated schema and data migrations.

You can even have multiple child models active at the same time!

How It Works

The polymorphic parent model contains the bare minimum required by Django for a user model. This is where your foreign keys will point to (via the AUTH_USER_MODEL setting), and this allows you to avoid schema migrations when changing child models.

Check out the django-polymorphic docs for more information on the underlying system that makes this possible.

Plugins

Several child models are also provided as usertype plugins for common use cases (email login, username login, etc.), along with a number of abstract models and mixin classes that you can use to create your own plugins.

For example:

# myproject/usertypes/foo/models.py

from django.utils.translation import ugettext_lazy as _
from polymorphic_auth.models import AbstractUser

class FooUser(AbstractUser):
    foo = models.CharField(unique=True)

    USERNAME_FIELD = 'foo'

    class Meta:
        verbose_name = _('user with foo login')
        verbose_name_plural = _('users with foo login')

Then just add your plugin to the INSTALLED_APPS setting and point to your model in the POLYMORPHIC_AUTH['DEFAULT_CHILD_MODEL'] setting:

# myproject/settings.py

AUTH_USER_MODEL = 'polymorphic_auth.User'
INSTALLED_APPS += ('myproject.usertypes.foo', )
POLYMORPHIC_AUTH = {'DEFAULT_CHILD_MODEL': 'foo.FooUser'}

ADMINS and MANAGERS Settings

The default app contains a post_migrate signal handler that will create superuser and staff accounts for each name and email in the ADMINS and MANAGERS settings, and write the credentials to sys.stdout (configurable).

Say goodbye to ./manage.py createsuperuser!

To add support to your custom plugins, override the AbstractUser.try_create classmethod and have it derive values for required fields from the name and email kwargs.

For example:

# myproject/usertypes/foo/models.py

import re

class FooUser(AbstractUser):
    ...

    @classmethod
    def try_create(self, **kwargs):
        email = kwargs.get('email', '')
        kwargs.setdefault('foo', re.sub(r'@.+', '', email))
        return super(FooUser, cls).try_create(**kwargs)

Admin

If more than one plugin is installed, you will be asked which type of user you want to create when adding a new user via the admin. If there is only one plugin installed, it will take you directly to the change form for that plugin.

You can customise the admin class for your plugins:

# myproject/usertypes/foo/admin.py

from myproject.usertypes.foo.forms import FooForm
from polymorphic_auth.admin import UserChildAdmin

class EmailUserAdmin(UserChildAdmin):

    # define custom features here

TODO

  • Registration system for plugins, instead of hard coding the provided ones and checking INSTALLED_APPS.

  • Authentication backend that checks all registered plugins, not just the one assigned to POLYMORPHIC_AUTH['DEFAULT_CHILD_MODEL'].

  • Make email field case insensitive.

Metadata

Release files for django-polymorphic-auth 0.4

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for django-polymorphic-auth 0.4
File Interpreter ABI Platform
django_polymorphic_auth-0.4-py2.py3-none-any.whl Python 3, Python 2 none any Details

Release files / django_polymorphic_auth-0.4-py2.py3-none-any.whl

Download URL django_polymorphic_auth-0.4-py2.py3-none-any.whl
Size 24.9 kB
Tags Python 2 Python 3
SHA-256 checksum
How to use checksums
8b856173479d7373774c192f8d9badad8ff47a5e043317db58d659ae359df896
BLAKE2b-256 checksum
How to use checksums
328c7a1c0ba62072a52a7ea957eae728afc400f79cea4ef7ab363c0e1c93d94a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No

Security for django-polymorphic-auth 0.4

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

Release history Release notifications | RSS feed

This release

0.4 This release

1 release file No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page