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

追記: 翔泳社さんからDjangoの書籍を出版するのでぜひ読んでみてください。


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

2019/04/08 追記: GithubのコードはPython3.7 Django2.2にupdateしています)

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

はじめに

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

スライド

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

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

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

ソースコード

github.com

Django 2.2, Python 3.7 で動作するソースコードを用意・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する必要がある。
  4. 扱わなければいけないレコードの数が増える。
    1. Djangosignals という機能を使うとUserモデル作成時にトリガーしてUserProfileモデルを自動で作成したりすることもできます。この機能を使うと場合によってはUserProfileモデルの管理をあまり意識することなくコーディングができるかもしれません。

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 を用意して利用しましょう。 今回は使っていませんが、UserChangeFormについても同様です。

from django.contrib.auth.forms import (
    UserCreationForm as BaseUserCreationForm,
    UserChangeForm as BaseUserChangeForm,
)
from .models import User


class UserCreationForm(BaseUserCreationForm):
    class Meta(BaseUserCreationForm.Meta):
        model = User


class UserChangeForm(BaseUserChangeForm):
    class Meta(BaseUserChangeForm.Meta):
        model = User

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], ... )
    :

またもう少し細かく制限するのもいいかもしれません。ハイフンとアンダースコアを別々としていては c-bata さんと c_bata さんが存在可能です。 個人的には次のようなvalidatorがおすすめです。

import re

from django.core import validators
from django.utils.deconstruct import deconstructible


@deconstructible
class UsernameValidator(validators.RegexValidator):
    regex = r'^[a-z0-9-]+$'
    message = (
        'Enter a valid username. This value may contain only'
        ' English small letters, numbers and hyphen.'
    )
    flags = re.ASCII

テストコード

from django.core.exceptions import ValidationError
from django.test import TestCase

from accounts.validators import UsernameValidator


class UsernameValidatorsTests(TestCase):
    def test_username_validator(self):
        valid_usernames = ['glenn', 'jean-marc001', 'c-bata']
        invalid_usernames = ['c_bata_', 'GLEnN', "o'connell", 'Éric', 'jean marc', "أحمد"]
        v = UsernameValidator()

        for valid in valid_usernames:
            with self.subTest(valid=valid):
                v(valid)

        for invalid in invalid_usernames:
            with self.subTest(invalid=invalid):
                with self.assertRaises(ValidationError):
                    v(invalid)

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認証

追記: 自分の勉強不足だったのですが、django-allauthはあらためて実装読んでみると複雑性を抑えつつよくできている印象です。自分が次実装するならこちらを使いそうです。あまりこれより下の内容は参考にしないほうがいいかもしれません。

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という独自の概念があります。今回紹介するproviderでは必要のないNonceなどのモデルも同時に作成されてしまいます。これらの概念とあわせて実装を理解するのは、Djangoに少し慣れたプログラマーであったとしても少々苦労するでしょう。データベースの状態をシンプルに保つことはアプリケーションの保守性を高める上で非常に重要です。Python界の巨匠 石本さんも次のようにおっしゃっています。

f:id:nwpct1:20180519132330p:plain

対応したいOAuthプロバイダーの数が少なく、social-auth-coreの理解に時間をかけたくない場合は、自前で実装するという選択も検討してみるといいかもしれません。social-auth-coreを使わずにGithub OAuth認証をする例を用意しました。これから紹介する認証フローを理解していれば、読めると思いますので今回は詳しく解説しませんが自分で実装が必要なときは参考にしてください。

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

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 をインストールして設定していきましょう。 今回は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 にのみ依存するように実装しました。

エキスパートPythonプログラミング 改訂2版が発売されました

改訂2版と書いてあるように、この本には初版があり日本語の翻訳書は2010年頃に出版されていました。 自分がPythonを書き始めたのが2014年頃だったのですが、当時通っていた学校の図書館で見つけてこの本を借りたことがあります。 プログラミングの勉強を初めたばかりの自分は、ほとんど何も理解出来ないまま返却したのを今でも覚えています。

今回は縁あって初版の翻訳メンバーである稲田さん、渋川さん、清水川さん、森本さんの4名と一緒に翻訳をすすめることになりましたが、4年前には何も理解できなかった自分がこれだけのベテラン陣と一緒に改訂2版の翻訳に関われていると思うと少し感慨深いです。

さて、初版から大幅に加筆され520ページとボリュームもあるので最初から最後まで読める人はあまりいないと思います。 必要になったらそのときに読んでみようと思っている方も多いと思いますが、参考までに自分が特に気に入っている章を3つあげておきます。

  • 3章 構文ベストプラクティス: クラスの世界
  • 7章: 他言語によるPython拡張: C拡張、Cython、ctypes
  • 13章 並行処理: マルチスレッド、マルチプロセス、非同期プログラミング

3章は初版から大きく書き換えられていて、7章と13章の内容に関しては、そのほとんどが改訂2版から新しく追加されています。 購入してくださった方は、ぜひチェックしてみてください。

Amazonでは2/26(月)から販売開始です。実は自分もそれを見て2/26(月)に発売かと思っていたのですが、書泉ブックタワーなど今日から発売している店舗があるようです。ぜひお近くの方は立ち寄ってみてください。

f:id:nwpct1:20180217143638j:plain

Mach APIとCPUレジスタ値の取得について

AbemaTV Advent Calendar の10日の記事です。 最近作っているツールの話をしようかと思ってましたがちょっと開発が間に合わなかったので、同期のiOSエンジニアから教えてほしいと言われたMach APIについて書きます。

あまりMach APIに関する資料は日本語・英語ともに多くないので、いざ使おうとするとドキュメントの情報が足りず苦労する。必要に応じてカーネルソースを読んだほうが早いことも多くあるため、この記事ではCPUレジスタ値の取り出しをベースに、カーネルソースを読む上で頭に入れておきたいMach APIのいくつかの概念についても解説する。

レジスタ値の取得 (Linuxの場合)

まずMacの話をする前にLinuxではどうしているかについて簡単に紹介しておく。

CPUレジスタにアクセスするとなると、Linuxのシステムでは ptrace() というシステムコールが利用される。 こちらのシステムコールは、特定のプロセスにアタッチしてメモリやCPUレジスタの中身をのぞいたり、書き換えたりすることができるため、 strace のようなシステムコールトレーサーや GDB のようなデバッガで利用されている。

最近だとGopherCon 2017のトークでもシステムコールトレーサーの実装を通したptraceの解説があったり、はてブホッテントリにも度々ptraceに関する記事が上がっていたので既にご存知の方も少なくないかもしれない。


GopherCon 2017: Liz Rice - A Go Programmer's Guide to Syscalls

日本語でもいくつか記事が見つかる。

ptraceについては英語・日本語ともに詳しい解説が既にありますが、これらのプログラムをMacで動かそうと思うと少し苦労する。 Darwinの提供している ptraceは、特定のプロセスにアタッチして処理を停止・再開を制御することはできますが、CPUレジスタの中身を覗いたり書き換えるための機能(PTRACE_GETREGSPTRACE_SETREGS)は存在しない。

Mach APIレジスタ値の取得

MacでもGDBとかを使えばレジスタの値は見れる。なのでもちろん PTRACE_GETREGSPTRACE_SETREGS の代わりになる機能が存在するはず。

f:id:nwpct1:20171211022715p:plain

ネットで検索してみると、 thread_get_state というAPIが検索でヒットした。

これらは Mach カーネル と呼ばれるカーネル基盤が提供していて、記事の中ではMach APIと呼ばれています。 Mach Kernelは マイクロカーネル として設計された (MachのGeneral Designや実装に関する話は、 Mach Overview に詳しくまとまっている)。 Uninformed - vol 4 article 3 によると、macOSで使用されているXNU(Appleが開発したOSカーネルDarwinの一部として公開されている)は、Mach KernelとともにBSDのコードを含んだ ハイブリッドカーネル と呼ばれるもの。しかしXNUのようにBSDMachを一緒に利用するハイブリッドカーネルでは、セキュリティポリシーの扱いが面倒になるらしい。 そこでMachは少し特殊なしくみでその問題を解決している。そのしくみについて勉強するうえでいくつか頭に入れて置かなければならない用語がある。

  • タスク(Tasks): リソース所有権の単位。いわゆるプロセスに近い。macOSのプロセスやPOSIXスレッド(pthreads)はMachのtaskと次の行で紹介するthreadの上で実装されているようだ。
  • スレッド(Threads): プロセス内のPCU実行単位。
  • メッセージ(Msgs): スレッド間の通信を提供するためにMachで使用されます。 メッセージは、データオブジェクトの集合で構成されています。 メッセージが作成されると、そのメッセージは、起動タスクが適切なポート権を持つポートに送信されます。 ポート権はタスク間でメッセージとして送信できます。 メッセージは宛先にキューイングされ、受信スレッドの自由度で処理されます。 Mac OS X では mach_msg() 関数を使用してポートとの間でメッセージを送受信する
  • ポート(Ports): カーネル制御通信チャネル。スレッド間でのメッセージのやりとりに使用する。ポート権限(Port rights)と呼ばれる権限をもつスレッドだけがそのポートにメッセージを送信できる。
  • ポートセット(Port Set): 名前の通りポートのコレクション。あるポートセットに所属するポートは全て同じメッセージキューを使用する。

Machのコンセプトとしては タスク(task) の起動や停止、タスクアドレス空間の操作等を行う際に、 ポート(port) に対して メッセージ(messages) を送信する。こうすることで、BSDのセキュリティ機能の影響を受けないようにしたらしい。 このことを頭に入れた上で、 thread_get_state について調べていこう。

thread_get_state の使い方を調べる

さてtaskやportといった概念を把握したところで、実際に thread_get_state を使ってプログラムカウンタの値をとってみる。 ちなみにx86x86_64のプログラムカウンタは、 Instruction Pointer と呼ばれていてx86_64では RIP レジスタがそれに相当するので、ソースコードを調べる際には RIP という単語が手がかりになりそう。

kern_return_t   thread_get_state
                (thread_act_t                     target_thread,
                 thread_state_flavor_t                   flavor,
                 thread_state_t                       old_state,
                 mach_msg_type_number_t         old_state_count);

http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_get_state.html

ドキュメントの解説によると、target_thread 引数で指定した特定のスレッドの実行状態(CPUレジスタなど)を取得することができるらしい。また第2引数の flavor で取得したい情報を指定するようだ。この説明からflavor の値をどれにするかによって kern_return_t 型の変数のどこかから目的のレジスタを取り出すことができそうだ。 しかし困ったことにドキュメントにはそれ以上の、説明が見当たらないのでDarwinの処理を追ってみる。

Darwin(XNU)カーネルソースコードmacOS 10.12.6 - Source から閲覧できる。 今回はGithubでもMirrorとして GitHub - apple/darwin-xnu: The Darwin Kernel (mirror) が公開されたのでそちらをcloneしてきた。

thread_get_state をみつける

cloneしたらまずは thread_get_state の処理を探してみる。

$ git clone git@github.com:apple/darwin-xnu.git
$ cd darwin-xnu
$ find . -name "*.c" | xargs grep -n "thread_get_state"
./osfmk/arm/status.c:79:machine_thread_get_state(
./osfmk/arm64/status.c:255:machine_thread_get_state(
./osfmk/chud/i386/chud_thread_i386.c:53:chudxnu_thread_get_state(
./osfmk/i386/pcb.c:1063:machine_thread_get_state(
./osfmk/kern/thread_act.c:456:thread_get_state(
...

引っかかった行を見ていくと次のコードが見つかった。

kern_return_t
thread_get_state(
    ...
        result = machine_thread_get_state(thread, flavor, state, state_count);

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/osfmk/kern/thread_act.c#L455-L503

machine_thread_get_state に渡しているため、もう少しほってみる。

machine_thread_get_state の処理を追う

$ git grep -n "machine_thread_get_state" *.c
osfmk/arm/status.c:79:machine_thread_get_state(
osfmk/arm64/status.c:255:machine_thread_get_state(
osfmk/i386/pcb.c:1063:machine_thread_get_state(
 ...

ARMではなさそうなので、 osfmk/i386/pcb.c が怪しそうだ。 中を見ると説明にあったとおり switch(flavor) とflavorの値に応じて何か処理が分岐している。

kern_return_t
machine_thread_get_state(
    thread_t thr_act,
    thread_flavor_t flavor,
    thread_state_t tstate,
    mach_msg_type_number_t *count)
{
    switch (flavor)  {
        ...
    }
}

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/osfmk/i386/pcb.c#L1056-L1479

x86_THREAD_STATE64 からの取得

ここでRIPを取る方法を調べるためにファイル内検索を書けてみるといくつか見つかった。まず1つは x86_THREAD_STATE64 を渡したときに RIPレジスタの値を取り出している。

     case x86_THREAD_STATE64: {
        x86_thread_state64_t    *state;
        x86_saved_state64_t *saved_state;
        ...
        state->rip = saved_state->isf.rip;
        ...

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/osfmk/i386/pcb.c#L1533-L1572

x86_THREAD_STATE からの取得

更にgrepで引っかかったところを読んでいると get_thread_state64 関数のなかでも、EIPにアクセスしていることが見て取れる。 machine_thread_get_state では次の行で get_thread_state64 を呼び出していることから、この処理が怪しそう。

static void
get_thread_state64(thread_t thread, x86_thread_state64_t *ts)
{
    ...
    ts->rip = saved_state->isf.rip;

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/osfmk/i386/pcb.c#L694-L724

     case x86_THREAD_STATE:
        {
        x86_thread_state_t  *state;
        ...
        if (thread_is_64bit(thr_act)) {
            ...
                get_thread_state64(thr_act, &state->uts.ts64);

https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/osfmk/i386/pcb.c#L1329-L1354

これらのコードから少なくとも x86_THREAD_STATE もしくは x86_THREAD_STATE64 のどちらかをflavor引数で指定すればRIPレジスタの値がとれそうだ。

ソースコード

flavorで指定する値はわかったので、早速実装してみる。 forkして生成した子プロセスのpidからthreadの一覧を取得し、 get_thread_statex86_THREAD_STATE を指定してレジスタ値を取得すればいい。 ソースコード全体はこちら。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <mach/mach.h>
#include <assert.h>
#include <mach/mach_types.h>


int main(int argc, char *argv[], char *envp[]) {
    pid_t pid = fork();
    if (pid == 0) {
        sleep(4);
        return KERN_SUCCESS;
    }

    kern_return_t err;
    mach_port_t task;
    err = task_for_pid(mach_task_self(), pid, &task);
    if (err != KERN_SUCCESS) {
        fprintf(stderr, "task_for_pid() failed\n");
        exit(EXIT_FAILURE);
    }

    err = task_suspend(task);
    if (err != KERN_SUCCESS) {
        fprintf(stderr, "task_suspend() failed\n");
        exit(EXIT_FAILURE);
    }

    thread_act_array_t threads = NULL;
    mach_msg_type_number_t threadCount;
    err = task_threads(task, &threads, &threadCount);
    if (err != KERN_SUCCESS) {
        fprintf(stderr, "task_threads() failed\n");
        exit(EXIT_FAILURE);
    }
    assert(threadCount > 0);

    x86_thread_state_t state;
    mach_msg_type_number_t count = x86_THREAD_STATE_COUNT;
    err = thread_get_state(threads[0], x86_THREAD_STATE, (thread_state_t)&state, &count);
    if (err != KERN_SUCCESS) {
        fprintf(stderr, "thread_get_state() failed\n");
        exit(EXIT_FAILURE);
    }

    printf("RIP = %llx\n", state.uts.ts64.__rip);
    printf("RAX = %llx\n", state.uts.ts64.__rax);
    printf("RCX = %llx\n", state.uts.ts64.__rcx);
    printf("RDX = %llx\n", state.uts.ts64.__rdx);
    printf("RBP = %llx\n", state.uts.ts64.__rbp);
    printf("RSI = %llx\n", state.uts.ts64.__rsi);
    printf("RDI = %llx\n", state.uts.ts64.__rdi);
    printf("R8  = %llx\n", state.uts.ts64.__r8);
    printf("R9  = %llx\n", state.uts.ts64.__r9);

    err = task_resume(task);
    if (err != KERN_SUCCESS) {
        fprintf(stderr, "task_resume() failed\n");
        exit(EXIT_FAILURE);
    }

    mach_port_deallocate(mach_task_self(), task);
    exit(EXIT_SUCCESS);
}

実行結果は次のとおり。

$ gcc print-rip.c -o print-rip -g -O0 -Wall
$ sudo ./print-rip
RIP = 7fffc6fe736f
RAX = 0
RCX = c
RDX = ffffffffffffffff
RBP = 7fff59ae2a30
RSI = 7fffc706d070
RDI = 0
R8  = 1c
R9  = a0

とれた 🎉

おわりに

オブジェクトファイルのバイナリフォーマットもELFではなくMach-Oというものだったり、標準CライブラリもlibSystem.d.dyldという動的ローダーの中にあったり、デバッグシンボルもdSYMの中に生成されたりstatic libraryも作れなかったり(static link binaryやstatic archive libraryというものは作れるみたいです)、Linuxの環境で勉強したものとは結構違っていて、はまったときにgdbデバッグするのも一苦労でした。 今回は記事も少し長くなったので、そのあたりの話はもう少し調べて整理してから記事にしようかと思います。

参考資料