c-bata web

@c_bata_ のメモ。python と Go が多めです。

Django における認証処理実装パターン

この資料は DjangoCongress JP 2018で話した「Djangoにおける認証処理実装パターン」 の解説記事になります。

何年か前に Djangoのユーザー認証まとめ という記事を書きました。今でもコンスタントに100PV/dayくらいアクセスのある記事なのですが内容が古く、自分が感じている注意点もあまり解説できていないためおすすめできる資料ではありません。今回はDjangoCongress JPにて発表の機会をいただけたのですが、この機会に認証処理についてまとめ直すと同時にこちらの資料とソースコード(Github)を合わせて用意することにしました。何かのお役にたてば幸いです。

はじめに

フレームワークの中にユーザーモデルまで定義されていることは、Djangoの最も特徴的な点かもしれません。このおかげで認証が必要なアプリケーションを高速に開発することができ、強力な管理画面もすぐに利用できます。しかし、Flask+SQLAlchemyとかでいちからユーザーモデルを定義するケースとは違って、Djangoではカスタマイズをするために内部の仕組みを正しく把握していないと思わぬところでエラーが起きたり意図しない挙動となる危険があるため、実装に悩んだことのある方も少なくないのではないでしょうか。本資料では認証処理をカスタマイズする際には抑えておかなければいけないポイントや注意するべき落とし穴を解説していきます。

スライド

PyCon JP 2017 のDjangoに関する発表の紹介

PyCon JP 2017でも認証や認可に関する発表がありました。それぞれ次のような内容です。

そのため今回は認証の カスタマイズ に絞った話をします。

ソースコード

github.com

Django 2.0, Python 3.6 で動作するソースコードを用意・Githubで公開しています。リポジトリ内の各PRがそれぞれのトピックのソースコードとなっています。

  1. 自作認証バックエンドを使ったEmail/Password 認証
  2. ユーザーモデルのカスタマイズ
  3. social-auth-core を使ったGithub OAuth認証
  4. social-auth-core を使わず from scratch で実装した Github OAuth認証

認証処理のカスタマイズ

Djangoの提供する認証機能

まずはDjangoが提供する認証処理についておさらいしましょう。 Djangoの認証処理に関する機能は django.contrib.auth パッケージにまとまっています。

用途 Formクラス Viewクラス
ログイン AuthenticationForm LoginView
ログアウト - LogoutView
パスワード更新 PasswordChangeForm PasswordChangeView PasswordChangeDoneView
パスワードリセット PasswordResetForm PasswordResetView PasswordResetDoneView PasswordResetConfirmView PasswordResetCompleteView
パスワード書き換え SetPasswordForm -
ユーザー登録 UserCreationForm -

参照: Built-in Auth Forms / Built-in Auth View Classes

組み込まれているFormクラスやViewクラスを列挙しましたが、パスワードリセットやパスワード更新用の画面など雑にWebサイト作るときは省略しちゃいそうなものまで標準で用意してくれています。それぞれの機能に関する関数ベースビューも提供されていますが、Django 1.11よりdeprecatedになっているので気をつけてください。また settings.py からは、 LOGIN_URLLOGIN_REDIRECT_URLLOGOUT_REDIRECT_URL を変更できます。

認証バックエンドによるカスタマイズ

標準では username/password によるログインが有効になっていますが、ここでは試しに email/password によるログインもできるようにしてみましょう。Djangoでは認証バックエンドというクラスを用意してあげれば認証処理を自由に拡張することができます。 django.contrib.auth.authenticate() が呼ばれると、 settings.pyAUTHENTICATION_BACKENDS により指定される認証バックエンドのリストの先頭から順に認証を試みます。1つが失敗しても次の認証バックエンドで認証を試み、全て認証に失敗すると認証失敗となります 1

それではEメールとパスワードで認証を行う認証バックエンドを定義して、 AUTHENTICATION_BACKENDS に追加してみましょう。 デフォルトでは、 認証バックエンドは2つのメソッドを定義しなければなりません 2

  • authenticate(request, **credentials): HttpRequestオブジェクトとあわせて認証に必要な情報を受け取り、ユーザーモデルのオブジェクトを返す。
  • get_user(user_id): ユーザーモデルの主キーを受け取り、ユーザーモデルのオブジェクトを返す。

一見動作するが、問題をかかえた例

それでは実際に認証バックエンドの例をみてみましょう。まずインターネットで検索したときに見かけたあまりおすすめできない例を紹介します。次のように実装してしまう気持ちはすごくわかりますし、自分も初学者のころうっかり実装してしまったことがありました。

from django.contrib.auth import get_user_model
from django.contrib.auth.backends import ModelBackend

UserModel = get_user_model()

class EmailAuthBackend(ModelBackend):
    def authenticate(self, username="", password="", **kwargs):
        if username is None:
            username = kwargs.get(UserModel.USERNAME_FIELD)
        try:
            user = UserModel.objects.get(email=username)
        except UserModel.DoesNotExist:
            return None
        else:
            if user.check_password(password) and self.user_can_authenticate(user):
                return user

usernameを入力する場所で、Eメールを入力するように変わるだけなので標準のModelBackendをベースにするのが簡単です。 authenticate メソッドだけを愚直に置き換えたこの認証バックエンドは、usernameとemailのどちらを入力しても認証に成功します。usernameとemailのフィールドの扱いが混ざっているこのコードは少しDirtyに見えますが、動作は一見問題なさそうです。 AUTHENTICATION_BACKENDS に追加して動かしてみましょう。

AUTHENTICATION_BACKENDS = [
    'django.contrib.auth.backends.ModelBackend',
    'accounts.backends.EmailAuthBackend',  # 追加
]

実際これは基本的にうまく動きます。フォームのラベルが username となってしまっていることだけ修正してあげれば、問題ないように見えますが実は1点無視できない問題があります。ログインフォーム上では username フィールドを入力する場所ですので、当然username の仕様にあわせたバリデーション処理を通ってきます。標準のusernameの仕様は、 「@」を受け入れますが twittergithub のようにそれを受け入れない仕様に変わった場合この方法は破綻します。

問題を修正した例

次のように定義するのがいいでしょう。

class EmailAuthBackend(ModelBackend):
    def authenticate(self, request, email=None, password=None, **credentials):
        try:
            user = UserModel.objects.get(email=email)
        except UserModel.DoesNotExist:
            return None
        else:
            if user.check_password(password) and self.user_can_authenticate(user):
                return user

認証バックエンドは定義できましたが、このバックエンドを設定してもまだログイン画面でEメールを入力してもログインできません。 Eメール用のログインフォームを定義して、そちらを利用する必要があります。

from django import forms
from django.contrib.auth import authenticate, get_user_model
from django.utils.text import capfirst
from django.utils.translation import gettext_lazy as _

UserModel = get_user_model()

class EmailAuthenticationForm(forms.Form):
    email = forms.EmailField(max_length=254,
                             widget=forms.TextInput(attrs={'autofocus': True}))
    password = forms.CharField(label=_("Password"), strip=False,
                               widget=forms.PasswordInput)
    error_messages = {
        'invalid_login': "Eメールアドレス または パスワードに誤りがあります。",
        'inactive': _("This account is inactive."),
    }

    def __init__(self, request=None, *args, **kwargs):
        self.request = request
        self.user_cache = None
        super().__init__(*args, **kwargs)

        # Set the label for the "email" field.
        self.email_field = UserModel._meta.get_field("email")
        if self.fields['email'].label is None:
            self.fields['email'].label = capfirst(self.email_field.verbose_name)

    def clean(self):
        email = self.cleaned_data.get('email')
        password = self.cleaned_data.get('password')

        if email is not None and password:
            self.user_cache = authenticate(self.request, email=email, password=password)
            if self.user_cache is None:
                raise forms.ValidationError(
                    self.error_messages['invalid_login'],
                    code='invalid_login',
                    params={'email': self.email_field.verbose_name})
            else:
                self.confirm_login_allowed(self.user_cache)

        return self.cleaned_data

    def confirm_login_allowed(self, user):
        if not user.is_active:
            raise forms.ValidationError(self.error_messages['inactive'], code='inactive')

    def get_user_id(self):
        if self.user_cache:
            return self.user_cache.id
        return None

    def get_user(self):
        return self.user_cache

用意できたら、ログイン用の Formクラスとして差し込みましょう。

from django.contrib.auth.views import LoginView
from django.urls import path

from accounts import views
from accounts.forms import EmailAuthenticationForm

urlpatterns = [
    path('login/', LoginView.as_view(form_class=EmailAuthenticationForm,
                                     template_name='accounts/login.html'), name='login'),
    :
]

このようにして Email/Password の実装ができます。 username と email のフィールドを混同せずしっかり別のものとして扱う点に注意してください。

ユーザーモデルのカスタマイズ

認証処理をカスタマイズしようとする際に、セットで悩むことが多いのがユーザーモデルのカスタマイズ方法です。

ユーザーモデルの拡張方法

ユーザーモデルの拡張方法はいくつかあります。

  • Userモデルに対して 1対1 の関係を持つUserProfileモデルを定義する
  • AbstractUser, AbstractBaseUser のサブクラスを定義する

それぞれ一長一短があるため、必要に応じて使い分けてください。

1対1の関係をもつモデルを定義する

UserProfileモデルを定義する方法は、次のように1対1の関係を持つモデルを用意します 3

class UserProfile(models.Model):
     user = models.OneToOneField(settings.AUTH_USER_MODEL)
     some_additional_columns1 = models.SomethingField(...)
     :

扱うデータの性質に応じてDB設計上の議論もあるかと思いますが、このやり方を採用したときの特徴は次のとおりです。

  1. カラムの追加定義のみが可能
    • first_namelast_name のようにサービスによっては不要なカラムがあるかと思いますが、これらを減らす際は後述する AbstractBaseUser クラスを継承して定義する必要があります
  2. ユーザーモデルに直接手を加える必要がない
    • 例えばサードパーティのライブラリがユーザーに紐づく情報を追加したいときは、この点が大きなメリットとなります
    • また後述するAbstractBaseUserやAbstractUserによるカスタマイズと共存可能ですので、必要に応じて使い分けたり両方使ってください。
  3. テーブルが分かれているので、SELECTする際にはクエリの数を増やすか、JOINする必要がある。

AbstractUser や AbstractBaseUser を継承したユーザーモデルの定義

AbstractUser は AbstractBaseUser を継承してカラム定義やメソッド定義を追加しています。これらは class Meta 内で abstract=True が定義されているため、 makemigrations 実行時にテーブル定義が生成されることはありません。 この2つのClassを継承する方法はどちらもほとんどやり方が変わらないので、今回は AbstractBaseUser を継承してユーザーモデルを定義、参照する方法を解説します。ユーザーモデルにどのようなカラムを定義したいのかをベースに考えてください。

標準のUserモデルは非常に多くのカラムが用意されています。 first_namelast_name などが定義されていますが、個人的につくるサービスでこれらのカラムが必要になることはありません。今回は自分がサービスを実装するときによく使うモデル定義を紹介します。

from django.contrib.auth.base_user import AbstractBaseUser
from django.contrib.auth.models import PermissionsMixin, UserManager
from django.contrib.auth.validators import ASCIIUsernameValidator
from django.core.mail import send_mail
from django.db import models
from django.utils import timezone
from django.utils.translation import ugettext_lazy as _


class User(AbstractBaseUser, PermissionsMixin):
    username_validator = ASCIIUsernameValidator()
    username = models.CharField(
        _('username'),
        max_length=150,
        unique=True,
        help_text=_('Required. 150 characters or fewer. Letters, digits and @/./+/-/_ only.'),
        validators=[username_validator],
        error_messages={
            'unique': _("A user with that username already exists."),
        },
    )
    email = models.EmailField(_('email address'), blank=True)
    profile_icon = models.ImageField(_('profile icon'), upload_to='profile_icons', null=True, blank=True)
    self_introduction = models.CharField(_('self introduction'), max_length=512, blank=True)
    is_admin = models.BooleanField(default=False)
    is_staff = models.BooleanField(
        _('staff status'),
        default=False,
        help_text=_('Designates whether the user can log into this admin site.'),
    )
    is_active = models.BooleanField(
        _('active'),
        default=True,
        help_text=_(
            'Designates whether this user should be treated as active. '
            'Unselect this instead of deleting accounts.'
        ),
    )
    date_joined = models.DateTimeField(_('date joined'), default=timezone.now)

    objects = UserManager()

    EMAIL_FIELD = 'email'
    USERNAME_FIELD = 'username'
    REQUIRED_FIELDS = ['email']

    class Meta:
        verbose_name = _('user')
        verbose_name_plural = _('users')
        db_table = 'users'

    def clean(self):
        super().clean()
        self.email = self.__class__.objects.normalize_email(self.email)

    def email_user(self, subject, message, from_email=None, **kwargs):
        send_mail(subject, message, from_email, [self.email], **kwargs)

Djangoに詳しい方は get_short_name()get_full_name() メソッドが定義されてないじゃないかと感じるかもしれませんが、Django 2.0からは定義する必要がありません。

ユーザーモデルの差し替え

定義したモデルは settings.pyAUTH_USER_MODELapp_label.ModelName の形式で指定します。

AUTH_USER_MODEL = 'accounts.User'

注意点としては、マイグレーションを実行した後の AUTH_USER_MODEL の差し替えは、多対多や外部キーの解決が難しくが非常に複雑になります。あとからマイグレーションをする必要がないよう、 AUTH_USER_MODEL によってユーザーモデルを差し替える作業は出来るだけシステムを稼働前に行ってください。

また会員登録時に UserCreationForm を使っていますが、これは username が絡む都合上デフォルトではAbstractBaseUser を継承したカスタムモデルで利用できません(AbstractUserは使えます)。次のように、 Meta.models で自作のモデルを指定した UserCreationForm を用意して利用しましょう。

from django.contrib.auth.forms import UserCreationForm as BaseUserCreationForm

from .models import User


class UserCreationForm(BaseUserCreationForm):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    class Meta:
        model = User
        fields = 'username',

usernameの取扱いに関する注意点

さてユーザーモデルの定義の解説は、非常に簡単で解説も非常に短いものでした。そのため今回はDjangoのユーザーモデルを定義する際に注意しておいて欲しい username の話をしようと思います。

以前のDjangoのバージョンでは、Python2を使っているときはASCII文字と数字、Python3を使っているときは unicode 文字が username に使うことができました。しかし、Django 2.0 における大きな変更としてPython 2サポートの終了があります。その上で次の質問に答えてください。

「c-bаtа」と「c-bata」、この2つは同じ username でしょうか?

$ python3
>>> "c-bata" == "c-bаtа"
False

一見同じに見えるこの2つの文字列はunicode上は別の文字です。 左辺に表示されている a という文字は U+0061 LATIN SMALL LETTER A ですが、右辺の а という文字は U+0430 CYRILLIC SMALL LETTER A です。punycode に encode することで紛らわしい文字がよくわかります。

>>> "c-bаtа".encode('punycode')
b'c-bt-73db'
>>> "c-bata".encode('punycode')
b'c-bata-'
>>>

別の文字ということは、それぞれ別のユーザーとして登録可能であることを示しています。これはなりすましといった何らかの攻撃に利用されるかもしれません。そのため先程定義したモデルのように username には ASCIIUsernameValidator を指定しておくことは、悩みごとの少なくなるいいテクニックです。仕様上問題なければぜひ付けておきましょう。

from django.contrib.auth.validators import ASCIIUsernameValidator

class User(AbstractBaseUser, PermissionsMixin):
    username_validator = ASCIIUsernameValidator()
    username = models.CharField(_('username'), validators=[username_validator], ... )
    :

unicodeには他にも多くのパターンがあり複雑ですが、 unicodedata パッケージを使って次のように正規化しておくといいでしょう。 UserCreationFormでは内部でこの処理を読んでいますが、UserCreationForm を使わず自分たちでバリデーションしてるようなコードや REST Framework の Serializer を作っている例などを見るとこの処理を忘れている例がしばしばあります。気をつけておきましょう。

>>> import unicodedata
>>> unicodedata.normalize('NFKC', 'アアァ')
'アアァ'
>>> unicodedata.normalize('NFKC', '㌀')
'アパート'
>>> unicodedata.normalize('NFKC', '9⁹₉⑨')
'9999'
>>> unicodedata.normalize('NFKC', 'Hℍℌ')
'HHH'

仕様上どうしてもUnicodeを使いたいという人は、The Tripartite Identity Pattern などを参考に設計を見つめ直してみてもいいかもしれません。

GithubによるOAuth認証

python-social-auth(social-auth-core) の紹介

1つだけならまだいいですが、複数のOAuthプロバイダーをサポートしたい場合、twittergithubFacebook全てのAPIを調べて自分で実装するのは少し面倒です。python-social-auth(social-auth-core)という人気のライブラリがあり、 social-auth-app-django というDjangoアプリケーションまで公開しています。今回はこちらを使ったOAuth認証の実装を解説します。

ただし、social-auth-core 4 は、様々なORM、フレームワーク、OAuthプロバイダーに対応するため抽象化のためのStorageやStrategy、Pipelineという独自の概念があります。これらの概念とあわせて実装を理解するのは、Djangoに少し慣れたプログラマーであったとしても少々苦労するでしょう。対応したいOAuthプロバイダーの数が少なく、social-auth-coreの理解に時間をかけたくない場合は、自前で実装するという選択も検討してみましょう。

OAuth認証の流れ

Githubを例にOAuth認証のおおまかな流れを簡単に解説します。

f:id:nwpct1:20180519132358p:plain

データベースの定義

まずはデータベースの構成について考えます。方法は1つではありませんが、基本的には次のようにデータベースをわけるでしょう。

f:id:nwpct1:20180519132417p:plain

  • id: 主キー
  • user_id: ユーザーモデルとのひもづける外部キー
  • provider: 'github' や 'facebook' などOAuthプロバイダーの識別子
  • uid: プロバイダーのシステム上でユーザーの識別に使われている一意な値

今回は同じSocialアカウントが別々のレコードで登録されないように、providerとuidでunique togetherの制約を付与しています。 これをDjangoのModel定義に落とし込むと次のようになります。

from django.conf import settings
from django.db import models


class Social(models.Model):
    """Social Auth association model"""
    user = models.ForeignKey(settings.AUTH_USER_MODEL,
                             related_name='socials',
                             on_delete=models.CASCADE)
    provider = models.CharField(max_length=32)
    uid = models.CharField(max_length=255)

    class Meta:
        unique_together = ('provider', 'uid')
        db_table = 'socials'

social-auth-core を使わないという選択肢

但し social-auth-core は、様々なWebFrameworkやORM、OAuth/OpenIDプロバイダーに対応するため多くの抽象化があります。そのせいで今回は必要のないNonceやAssociationといったモデルも同時に作成されてしまいます。データベースの状態をシンプルに保つことはアプリケーションの保守性を高める上で非常に重要です。Python界の巨匠 石本さんも次のようにおっしゃっています。

f:id:nwpct1:20180519132330p:plain

そこでsocial-auth-coreを使わずにGithub OAuth認証をする例を用意しました (バリデーション処理などが抜けていたり少し実装が雑な点はあります)。最初に紹介した認証フローを理解していれば、読めると思いますので今回は詳しく解説しませんが自分で実装が必要なときは参考にしてください。

https://github.com/c-bata/django-auth-example/pull/4

social-auth-core を使った実装

次は social-auth-core をインストールして設定していきましょう。 今回はGithub OAuthを実装していきます。

$ pip install social-auth-core==1.7.0 social-auth-app-django==2.1.0

インストールが出来たら settings.py を変更していきます。 social_app_django が、Djangoのアプリケーションであると説明しましたが social-core の方もDjangoを意識したデザインになっていて、social_core のbackendsと呼ばれる概念はDjangoの認証バックエンドとしての仕様を満たしています。 今回はGithubなので、次のように AUTHENTICATION_BACKENDS を設定してください。

INSTALLED_APPS = [
    :
    'social_django',
    'socials.apps.SocialsConfig',
]


AUTHENTICATION_BACKENDS = (
    'django.contrib.auth.backends.ModelBackend',
    'social_core.backends.github.GithubOAuth2',
)

TEMPLATES = [
    {
        'OPTIONS': {
            'context_processors': [
                :
                'socials.context_processors.backends',
                'socials.context_processors.login_redirect',
            ],
        },
    },
]

SOCIAL_AUTH_GITHUB_KEY = os.getenv("SOCIAL_AUTH_GITHUB_KEY", "")
SOCIAL_AUTH_GITHUB_SECRET = os.getenv("SOCIAL_AUTH_GITHUB_SECRET", "")

GithubのApplication KeyとApplication Secretが必要です。 Github Settingsから登録を行いましょう。コールバックURLは次のように http://127.0.0.1:8000/social/complete/github とします。

f:id:nwpct1:20180519132437p:plain

次はCallback等のエンドポイントを追加していきます。URLは social-app-django に習って次のようにしました。

from django.urls import path

from socials import views

app_name = 'social'

urlpatterns = [
    path("login/<provider>", views.auth, name="begin"),
    path("complete/<provider>", views.complete, name="complete"),
    path("disconnect/<provider>", views.disconnect, name="disconnect"),
    path("disconnect/<provider>/<int:association_id>", views.disconnect,
         name="disconnect_individual"),
]

プロジェクトの urls.py でincludeもしておきます。

urlpatterns = [
    :
    path("social/", include("socials.urls")),
    path('admin/', admin.site.urls),
]

次は view関数を定義します。

from django.conf import settings
from django.contrib.auth import REDIRECT_FIELD_NAME, login
from django.http import Http404
from django.urls import reverse
from django.views.decorators.cache import never_cache
from social_core.actions import do_auth, do_complete, do_disconnect
from social_core.backends.utils import get_backend
from social_core.exceptions import MissingBackend
from social_django.strategy import DjangoStrategy
from social_django.models import DjangoStorage
from social_django.views import _do_login as login_func

BACKENDS = settings.AUTHENTICATION_BACKENDS


@never_cache
def auth(request, provider):
    redirect_uri = reverse("social:complete", args=(provider,))
    request.social_strategy = DjangoStrategy(DjangoStorage, request)
    try:
        backend_cls = get_backend(BACKENDS, provider)
        backend_obj = backend_cls(request.social_strategy, redirect_uri)
    except MissingBackend:
        raise Http404('Backend not found')

    return do_auth(backend_obj, redirect_name=REDIRECT_FIELD_NAME)


@never_cache
def complete(request, provider):
    redirect_uri = reverse("social:complete", args=(provider,))
    request.social_strategy = DjangoStrategy(DjangoStorage, request)
    try:
        backend_cls = get_backend(BACKENDS, provider)
        backend_obj = backend_cls(request.social_strategy, redirect_uri)
    except MissingBackend:
        raise Http404('Backend not found')

    return do_complete(backend_obj, login_func, request.user,
                       redirect_name=REDIRECT_FIELD_NAME, request=request)


@never_cache
def disconnect(request, provider, association_id=None):
    request.social_strategy = DjangoStrategy(DjangoStorage, request)
    try:
        backend_cls = get_backend(BACKENDS, provider)
        backend_obj = backend_cls(request.social_strategy, "")
    except MissingBackend:
        raise Http404('Backend not found')

    return do_disconnect(backend_obj, request.user, association_id,
                         redirect_name=REDIRECT_FIELD_NAME)

ログイン画面に Github によるログインボタンを追加。

<a href="{% url 'social:begin' 'github' %}">Github でログイン</a>

Pipeline の仕組み

Pipeline は python-social-core の最も優れた概念です。Pipelineは、OAuthの流れの中でいくつかのポイントに処理を差し込めるフックポイントを提供してくれます。

f:id:nwpct1:20180519132452p:plain

例えば↑のポイントにフックして処理を記述することができますが、これは何が嬉しいのでしょうか? OAuthプロバイダーのシステム上での表現と自分たちのサービスの表現にはいくつか違いがあります。 例えば、FacebookがGenderを50種類以上用意しているのに対して、自分たちのサービスでは 2-4 種類しか定義したくないこともあるでしょう。プロフィール画像URLのスキームが http の場合、Mixed Contentを避けるために画像をダウンロードしてhttpsのエンドポイントで自前でホストする必要があるケースもあるかもしれません。

# pipeline.py
def save_profile(backend, user, response, *args, **kwargs):
    if backend.name == 'facebook':
        user.gender = sanitize_gender(response.get('gender'))
        :
        profile.save()

定義したPipelineは次のように設定します。

SOCIAL_AUTH_PIPELINE = (
    'app_label.pipeline.save_profile',
    :
)

こういった外部のサービスから取得するユーザー情報を自分たちのサービスに合わせて加工することができます。簡単に拡張できるようになっているので、ぜひドキュメント を参考に利用してみてください。

まとめ

Djangoにおけるユーザー認証のカスタマイズにフォーカスして解説を行いました。 誰も教えてくれないはまりどころもありますので、この資料を参考に進めてください。


  1. ユーザは一度認証されると、Djangoはどのバックエンドで認証されたのかをユーザーセッションに保存します。セッションが有効な場合は、同じバックエンドを利用する時にキャッシュとしてそのユーザーが認証済みかどうかチェックします。強制的に別の方法で再度認証させたい場合は、セッションデータをクリアしてください。クッキーを削除するか、 Session.objects.all().delete() で消すことができます。

  2. 認証バックエンドには、 has_permget_all_permissions といったユーザーオブジェクトの権限確認(認可)のためのメソッドを定義することもできます。ただし、話が大きくなりすぎるため今回は扱いません。

  3. ユーザーモデルを外部キーとするときに get_user_model でもできそうに見えますが、こちらはimport loopが発生する問題があるので避けてください。 settings.AUTH_USER_MODEL を使いましょう。

  4. 特にpython-social-authの実装は social-core の意味のないラッパーのようになっていて、一見あまり綺麗でないように感じました。これは python-social-auth が悪いというわけではなく、人気のあるライブラリが後方互換を保ったまま初期の設計の負債を修正するにはこのようにならざるを得なかったことも想像できます。実際omabさんも2016年移行 python-social-auth にはcommitしていなくて、django-social-appもsocial-coreだけに依存しています。そこで今回の実装も social-auth-core にのみ依存するように実装しました。