Djangoを使ってデータベースを持たないAPI認証を行う

この記事は Django Advent Calendar 2017 20日目の記事です。

先日、満を持してバージョン2.0がリリースされました。
ただ、今回は新しい機能の紹介ではなく、1.xでも実装可能な「API認証」について書きます。

アジェンダ

  • この記事を書こうと思ったきっかけ
  • API認証の実装
  • まとめ

この記事を書こうと思ったきっかけ

以前、こちらにも書いたのですが、私は自分がつくったシステムのログイン~ログアウト処理に、これまた自分で作ったGo(Gin)のAPIを利用しています。
※最近はソーシャルログインなど外部サービスとの連携が楽にできるのですが、自分の勉強のためにこのようにしています。

で、以前ASP.NETでつくったレシピ管理ツールを今年Djangoに移行しまして、そこでもAPI認証をすることにしました。
CakePHP3やLaravelでは比較的簡単にできたのですが、Djangoは少し癖があったので、備忘も兼ねて書き残しておこうと思ったのがきっかけです。

API認証の実装

手順は大きく4つです。

  1. 認証用ユーザモデルの作成
  2. 認証ミドルウェアの作成
  3. 認証バックエンドの作成
  4. 設定ファイルの変更

通常、Djangoではマイグレーション時にauth_userテーブルが生成され、そこでユーザ情報を管理します。
グループやバーミッションなど細かい設定もできるのですが、今回はそれらは使用しません。

カスタムユーザモデルの作成

AbstratUserを継承した、独自ユーザーモデルを作成します。

セッションにsigned_cookieを利用しているためJSON変換処理を用意しています。

カスタム認証ミドルウェアの作成

django.contrib.auth.middleware.AuthenticationMiddlewareを参考に、以下のようなカスタムミドルウェアを作成します。

認証バックエンドの作成

Django標準の認証バックエンドとしてModelBackend(データベースを利用)やRemoteUserBackend(ヘッダのユーザー名を利用)が用意されていますが、
今回はAPI認証のため独自のバックエンドファイルを用意します。

設定ファイルの変更

最後に、settings.pyを修正します。

以上で実装完了です。

まとめ

Djangoには標準で管理画面がついてきますが、こちらはDBありきの実装なので、認証・認可をAPIで乗り切ろうと思うとかなり大変です。
標準の管理画面を利用する場合は嫌でもデータベースを使うことになるので、その場合は素直にテーブル管理しましょう。

一応、上記コード上にもコメントで記載していますが、結局のところ認証ユーザとauth_userテーブルを一旦同期させることになりそうです。

主な手順

  • ApiUserauth_userとして利用
  • API認証時、auth_userにレコードがなければ追加
  • リレーションの維持にはその値を利用

この実装を通して、Djangoが認証をどのように行っているかを学べたのは良い経験でした。
まだまだ知らない機能が多いので、これからも機能追加しつつ楽しんで開発出来たらと思います。

一部記事用に修正しましたが、今回利用したソースコードの元はこちらにありますので、良ければご覧ください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA