【Django】LogoutViewの使い方（クラスベースビューでのログアウトの実現）

このページにはプロモーションが含まれています

このページでは LogoutView の使い方について説明していきます。

この LogoutView は View というクラスのサブクラスの１つであり、ビューをクラスベースで作成する際に利用するクラスとなります。この View のサブクラス を継承し、さらにクラス変数を定義したりメソッドをオーバーライドすることで、あなたが開発したいアプリに応じたビューを作成することが可能となります。

この辺りのクラスベースビューやクラスベースビューの作り方については下記ページで解説していますので、詳しくはこちらをご参照ください。

【Django入門１５】クラスベースビューの基本

そして、名前の通り LogoutView はログアウトを実現するための View のサブクラス となります。そもそもログアウトはログイン状態のユーザーが行うもので有り、ログインを実現するのは LoginView の役割となります。この LoginView に関しては下記ページで解説していますので、LoginView に関しては下記ページを参照していただければと思います。

【Django】LoginViewの使い方（クラスベースビューでのログインの実現）

このページで目指すことは、LogoutView を利用し、ログアウトをクラスベースビューで実現していくことになります。また、このページでは LogoutView の使用例は示さず、先ほど紹介した上記の LoginView でまとめて示すようにしています。そのため、LogoutView の使用例に関しては上記ページの LoginView の利用例を別途参照していただければと思います。

Contents

LogoutView
- auth アプリから提供されるクラス
- LogoutView の処理の流れ
LogoutView でのクラスベースビューの作り方
LogoutView のクラス変数
LogoutView のメソッド
- LogoutView のメソッド一覧
LogoutView が生成するコンテキスト
LogoutView の利用例
まとめ

`LogoutView`

まずは、LogoutView がどういったクラスであるのかについて解説していきたいと思います。

名前の通り、LogoutView はログアウトを実現するクラスとなります。

`auth` アプリから提供されるクラス

このサイトでは、今まで View のサブクラス として CreateView や UpdateView 等を紹介してきましたが、これらは django.views.generic から提供されるクラスでした。そのため、これらは django.views.generic から import して利用する必要がありました。

それに対し、LogoutView に関しては、LoginView と同様に django.contrib.auth.views から import して利用することになります。

LogoutViewのimport

from django.contrib.auth.views import LogoutView

LogoutView は auth というアプリで定義されるクラスとなりますので、上記のように import の仕方が他の View のサブクラス とは異なる点に注意してください。

`LogoutView` の処理の流れ

続いて LogoutView の処理の流れについて説明しておきます。

`POST` のリクエストを受け取った際にログアウトが実行される

まず、LogoutView は POST メソッドのリクエストのみに対応するビューとなります。

MEMO

実は、Django のバージョン 4 までは GET メソッドのリクエストにも対応しており、GET メソッドのリクエストを受け取った時も POST メソッドのリクエストを受け取った時も同じ処理が実行されるようになっていました

ただし、Django のバージョン 5 以降では POST メソッドのリクエストのみに対応するように変更されていますので、この点にはご注意ください

そして、LogoutView は POST メソッドのリクエストを受け取ると、LogoutView の post メソッドを実行し、そのメソッドの中でログアウト処理が行われるようになっています。そのため、ユーザーが LogoutView に紐づけられる URL ヘ POST メソッドのリクエストを送信すると、そのユーザーがログアウト状態（非ログイン状態）となることになります。また、このログアウト処理は、auth から提供される logout 関数の実行によって行われることになります。

下記ページで解説している通り、関数ベースビューの場合はログアウトを行うために、開発者自身が logout 関数を実行する処理を実装する必要があったのですが、クラスベースビューの場合は、LogoutView で logout 関数を実行する処理が実装されているため、LogoutView を継承するクラスを定義するだけでログアウトが実現できることになります。

ログアウトは `AUTH_USER_MODEL` のインスタンスに対して実施される

また、ログアウトはユーザーを非ログイン状態に移行するための処理であり、この『ユーザー』とは、具体的には settings.py で定義した AUTH_USER_MODEL に指定されたモデルクラスのインスタンスとなります。settings.py で AUTH_USER_MODEL が定義されていない場合は、AUTH_USER_MODEL はデフォルトの auth.User、すなわち auth アプリであらかじめ定義された User というモデルクラスのインスタンスがユーザーとなります。

このページでは説明はしませんが、ログインに関しても AUTH_USER_MODEL のインスタンスに対して実施されることになりますので、User　以外、例えば下記ページで解説している カスタムユーザー のインスタンスに対してログアウト・ログインを実施したいような場合は、settings.py での AUTH_USER_MODEL の定義が必要となります。

【Django入門９】カスタムユーザーによるユーザー管理

ログアウトの場合は、あまり意識する必要はないのですが、この AUTH_USER_MODEL のインスタンスに対してログインやログアウトが実行されるという点は覚えておくとよいと思います。

ログアウト後にはレスポンスの返却が行われる

さらに、ログアウト処理が実行された後には、基本的には特定の URL へのリダイレクトレスポンスの返却が行われることになります。もしくは、LogoutView を継承するクラスのクラス変数等の定義の仕方によっては、特定のページを表示するための HTML をボディとするレスポンスの返却を行うようにすることもできます。このあたりに関しては、次の LogoutView でのクラスベースビューの作り方で説明します。

`LogoutView` でのクラスベースビューの作り方

では、次は LogoutView でクラスベースビューを作成する手順について説明していきます。

LogoutView でのクラスベースビューの作り方に関しても他の View のサブクラス と同様となります。

つまり、views.py に LogoutView を継承するクラスを定義し、そのクラスでクラス変数やメソッドを定義して LogoutView 側で定義されているクラス変数の上書き・メソッドのオーバーライドを行なうことで、ビューを作成していきます。これにより、LogoutView の特徴を活かしながら自身のウェブアプリに応じたビューにカスタマイズしていくことが可能となります。

基本的には、LogoutView で行われるのはログアウト処理とレスポンスの返却のみです。ログアウト処理に関しては、単に logout 関数が実行されるだけなので、特にカスタマイズが必要となる点はありません。それに対し、レスポンスの返却に関してはクラス変数等でカスタマイズすることができ、クラス変数等の定義の仕方によって、リダイレクトレスポンス or テンプレートファイルから生成した HTML をボディとするレスポンスのどちらを返却するのかをカスタマイズすることが可能です。

ここからは、このログアウト後に返却されるレスポンスについて、詳細を説明していきます。

レスポンスの種類のカスタマイズ

前述の通り、LogoutView でログアウト後に返却するレスポンスは、下記のいずれかとなります。

リダイレクトレスポンス
テンプレートファイルから生成した HTML をボディとするレスポンス

リダイレクトレスポンスが返却されるのは、リダイレクト先の URL が適切に設定されている場合で、リダイレクト先の URL は下記のいずれかによって設定することが可能です。なので、下記のいずれかの方法でリダイレクト先の URL が設定されていれば、基本的にはログアウト後にリダイレクトレスポンスが返却されることになります。複数の方法でリダイレクト先の URL が設定されている場合、下記の 1. → 2. → 3. の順序で優先してリダイレクト先の URL が設定されることになります。

リクエストの URL のクエリパラメーターでリダイレクト先の URL を設定する
LogoutView のサブクラスでクラス変数 next_page を定義する
settings.py で LOGOUT_REDIRECT_URLを定義する

ただし、ログアウトを要求するためのリクエストの URL と、リダイレクト先の URL が同じ場合は、URL が不適切に設定されていると判断されます。そして、リダイレクト先の URL が不適切に設定されている場合や、そもそも上記の方法でリダイレクト先の URL が設定されていない場合は、ログアウト後にテンプレートファイルから生成した HTML をボディとするレスポンスが返却されることになります。

したがって、LogoutView を継承するクラスでログアウト後にリダイレクトレスポンスを返却したい場合は、上記で示した３つの方法のいずれかでリダイレクト先の URL を設定するようにしてやれば良いです。逆に、ログアウト後にテンプレートファイルから生成した HTML をボディとするレスポンスを返却したい場合は、リダイレクト先の URL の設定を行わなければよいです。この場合は、LogoutView を継承するクラスで利用するテンプレートファイルのパスをクラス変数 template_name で設定する or LogoutView のデフォルトのテンプレートファイルのパスにテンプレートファイルを設置する必要があります。このあたりは、後述の template_name の節で解説します。

また、上記のように、リダイレクト先の URL を設定する方法は３つありますが、基本的には 2. or 3. の方法でリダイレクト先の URL を設定するのが楽だと思います。これらの詳細は、後述の next_page の節で解説します。また、1. に関しては、後述の redirect_field_name で補足します。

ログインの実現

また、ログアウトはログイン状態のユーザーを非ログイン状態に設定する処理ですので、ログアウト機能を実現するのであればログイン機能も実現しておく必要があります。

このログインを LoginView を利用してクラスベースビューで実現する方法については下記ページで解説していますので、ログインの実現方法の詳細に関しては下記ページを参照していただければと思います。

【Django】LoginViewの使い方（クラスベースビューでのログインの実現）

非ログインユーザーのアクセス制限

また、ログイン機能を搭載するウェブアプリにおいては、非ログイン状態のユーザーからのアクセスを拒否するようにすることも多いです。こういった非ログイン状態のユーザーに対するアクセス制限は LoginRequiredMixin を利用することで簡単に実現できます。これに関しても下記ページで解説していますので、詳細は下記ページを参照していただければと思います。

【Django】LoginViewの使い方（クラスベースビューでのログインの実現）

`LogoutView` のクラス変数

では、次は LogoutView で定義されているクラス変数の紹介を行なっていきます。これらのクラス変数を LogoutView を継承するクラスで定義し直して上書きすることでクラスの動作のカスタマイズを行うことが可能となります。

前述の通り、LogoutView がリクエストを受け取った際には、まずログアウト処理が実行されるようになっています。この処理に関しては基本的にカスタマイズは不要だと思います。また、ログアウト処理の後は、レスポンスの種類のカスタマイズで説明したように、リダイレクト先の URL が設定されている場合はリダイレクトレスポンスが、それ以外の場合はテンプレートファイルから生成した HTML をボディとするレスポンスが返却されるようになっています。

このあたりの、リダイレクト先の URL や、さらにテンプレートファイルを利用する場合のテンプレートファイルのパスに関しては、必要に応じて LogoutView のサブクラスにクラス変数を定義してカスタマイズする必要があります。そのあたりに注目して、LogoutView のクラス変数について確認していきたいと思います。

`LogoutView` のクラス変数の一覧

この LogoutView で定義されるクラス変数には下記のようなものが存在します。

redirect_field_name
next_page
template_name
extra_context (ListView)
template_engine (ListView)
response_class (ListView)
content_type (ListView)

上側の３つ、つまり redirect_field_name、next_page、template_name に関しては、前述のリダイレクト先の URL やテンプレートファイルのパスのカスタマイズ用のクラス変数となります。

これら以外に関しては、ListView の解説ページで既に説明済みですし、特に LogoutView に特化した説明も不要ですので、詳細を知りたい方は別途下記の ListView の解説ページを参照していただければと思います。これらのリンクテキストにも、ListView の解説ページへのリンクを設定させていただいています。

【Django】ListViewの使い方（クラスベースビューでの一覧リストページの実現）

ということで、ここからは、redirect_field_name と next_page と template_name の解説を行なっていきます。

`redirect_field_name`

まずは、redirect_field_name について解説します。

リダイレクト先の URL を指定する変数名を設定するクラス変数

レスポンスの種類のカスタマイズでも説明したように、リダイレクト先の URL はクエリパラメーターによって設定可能です。このリダイレクト先の URL を指定するクエリパラメーターの変数名を指定するのが、クラス変数 redirect_field_name となります。このクラス変数 redirect_field_name のデフォルト値は 'next' なので、クラス変数 redirect_field_name を定義しない場合は、リダイレクト先の URL をクエリパラメーターで指定する場合、その URL は変数名 next で指定する必要があります。

この場合、例えばログアウトを実施する URL（LogoutView のサブクラスにマッピングされた URL）が /forum/logout/ であり、さらにログアウト後のリダイレクト先の URL に /forum/login/ を指定したいのであれば、下記のような URL を LogoutView が受け取った場合、ログアウト後には /forum/login/ へのリダイレクトレスポンスが返却されることになります。

もちろん、?next= の後ろ側の URL を変更してやれば、ログアウト後のリダイレクト先の URL を変化させることができます。

/forum/logout/?next=/forum/login/

で、上記はクラス変数 redirect_field_name がデフォルト値、つまり 'next' の場合の話で、LogoutView のサブクラスでクラス変数 redirect_field_name を定義することで、クエリパラメーターでリダイレクト先の URL を指定する変数名を変化させることが可能です。例えば、redirect_field_name = 'redirect_url' を定義しておけば変数名が redirect_url に変化するため、上記と同様のリダイレクトレスポンスの返却は下記の URL の指定によって実現されることになります。

/forum/logout/?redirect_url=/forum/login/

特にこだわりが無ければ、クラス変数 redirect_field_name は定義しなくても良いと思いますが、クラス変数 redirect_field_name の役割については覚えておくとよいと思います。

URL にクエリパラメーターを追加したリクエストの送信方法

また、レスポンスの種類のカスタマイズでも説明したように、複数の方法でリダイレクト先の URL が設定された場合は、このクエリパラメーターで指定される URL が最優先で設定されることになります。

ただ、ログアウトの場合は、クエリパラメーターでログアウト後のリダイレクト先の URL を設定する機会は少なく、基本的には後述のクラス変数 next_page の定義や settings.py での LOGOUT_REDIRECT_URL の定義によってリダイレクト先の URL を設定することが多いと思います。そして、これらの方が簡単にリダイレクト先の URL を設定することができます。

クエリパラメーターでログアウト後のリダイレクト先の URL を設定する場合は、ログアウト実行用のボタン等をページに設け、さらにそのボタンが押された時にリクエスト送信先の URL にクエリパラメーターを追加するようウェブアプリを開発する必要があります。

そして、このようなページは HTML によって表示され、さらに HTML はテンプレートファイルから生成されるため、結局は、クエリパラメーターでリダイレクト先の URL を指定したい場合、テンプレートファイルを上手く作る必要があることになります。

例えば、下記のようなテンプレートファイルを作成すれば、太字部分によってクエリパラメーターでリダイレクト先の URL が指定されることになりますが（redirect_field_name = 'redirect_url' が指定されていることを前提としたテンプレートファイルになります）、わざわざテンプレートファイルでクエリパラメーターを追加するようにするより、next_page や settings.py でリダイレクト先の URL を指定してやった方が楽だと思います。

クエリパラメーター付きのURL

<form id="logout-form" method="post" action="/forum/logout/?redirect_url=/forum/login/">
    {% csrf_token %}
    <button type="submit">ログアウト</a>
</form>

`next_page`

続いて next_page について説明します。

レスポンスの種類のカスタマイズでも説明したように、next_page はログアウト後のリダイレクト先の URL を設定するためのクラス変数になります。このクラス変数 next_page は、クエリパラメーターでリダイレクト先の URL が指定されていない場合に参照されることになります。next_page のデフォルトは None となります。

next_page には URL を表す文字列だけでなく、urls.py で設定する URL の名前等も指定可能です。

例えば下記のように LogoutView のサブクラスとして UserLogout を定義した場合、この UserLogout がリクエストを受け取ってログアウトが実行された後には、URL の名前が 'login' に設定されている URL へのリダイレクトレスポンスが返却されることになります。

next_pageの定義例

class UserLogout(LogoutView):
    next_page = 'login'

ついでに、settings.py での LOGOUT_REDIRECT_URL についても説明しておくと、クエリパラメーターでリダイレクト先の URL が指定されておらず、さらにクラス変数 next_page も定義されていない場合は、この settings.py で定義された LOGOUT_REDIRECT_URL の URL がログイン後のリダイレクト先の URL に設定されることになります。

LOGOUT_REDIRECT_URL にも URL を表す文字列だけでなく、urls.py で設定する URL の名前等も指定可能です。

例えば下記のように settings.py に対して LOGOUT_REDIRECT_URL の定義を追加しておけば、ログアウト後に /accounts/login/ をリダイレクト先とするリダイレクトレスポンスが返却されるようになります。

LOGOUT_REDIRECT_URLの定義例

LOGOUT_REDIRECT_URL = '/accounts/login/'

この settings.py での LOGOUT_REDIRECT_URL の定義によるリダイレクト先の URL の設定は、プロジェクト内の全アプリに対して適用されるという点に注意してください。例えば Django で開発するウェブアプリ（プロジェクト）には、デフォルトで管理画面が含まれます。なので、管理画面でのログアウト後のリダイレクト先の URL にも settings.py での LOGOUT_REDIRECT_URL の定義によるリダイレクト先の URL の設定が適用されることになります。

なので、プロジェクト内の全アプリでログアウト後のリダイレクト先の URL を統一したい場合は、settings.py での LOGOUT_REDIRECT_URL の定義によってリダイレクト先の URL の設定を行い、それ以外の場合は、クラス変数 next_page の定義によってリダイレクト先の URL の設定を行うようにするので良いと思います。

さらに、もし、ウェブアプリにログアウト実施用のボタンが複数存在し、そのボタンごとにリダイレクト先を変更したい場合は、クエリパラメーターによってリダイレクト先の URL を設定するようにしてやれば良いと思います。

`template_name`

また、リダイレクト先の URL が設定されていない場合は、テンプレートファイルから生成された HTML をボディとするレスポンスが返却されることになります。

そして、そのテンプレートファイルのパスは、クラス変数 template_name によって指定することが可能です。この template_name の役割自体は、他の View のサブクラス における template_name と全く同じになります。ただし、LogoutView の template_name ではデフォルトのテンプレートファイルのパスが若干特殊で、このパスは 'registration/logged_out.html' となります。

もっと具体的に言えば、このパスは、Django のインストール先のフォルダからの相対パスで下記となります。

contrib/admin/templates/registration/logged_out.html

で、このパスには、admin (管理画面) アプリで用意された logged_out.html が既に設置されていますので、テンプレートファイルを別途用意しなくても、リダイレクト先の URL が設定されていなければ上記のテンプレートファイルから HTML が生成され、それをボディとするレスポンスが返却されることになります。その時に表示されるページは下図のようなものになります（言語設定等によって見た目は変化します）。

ということで、LogoutView の場合は、クラス変数 template_name を定義しなかった場合、既に admin アプリで用意債れたテンプレートファイルが利用されてページ表示が行われることになります。もちろん、それで問題ないのであればクラス変数 template_name の定義は不要ではあるのですが、ログアウト後に表示されるページとして logged_out.html から生成されるページが気に入らないのであれば、クラス変数 template_name を定義してテンプレートファイルのパスを指定し、そのパスに自身で作成したテンプレートファイルを設置することが必要となります。

`LogoutView` のメソッド

次に LogoutView の持つメソッドを紹介していきます。LogoutView を継承したクラスを定義し、そのクラスで LogotView の持つメソッドをオーバーライドしてやることで LogoutView とは異なる動作のクラスを実現することができるようになります。

ただ、LogoutView の場合はログアウトを実施し、その後にレスポンスを返却するという典型的な処理の流れが既に実現されているため、わざわざオーバーライドを行なって、その処理の流れを変更することは少ないと思います。

ということで、ここではオーバーライドの例などは示さず、LogoutView のメソッドの一覧のみを示すようにしたいと思います。

`LogoutView` のメソッド一覧

LogoutView の持つメソッドの一覧は下記のようになります。あくまでもクラスのカスタマイズ目的でオーバーライドを行う可能性のあるものを挙げており、as_view などのカスタマイズは行わないであろうメソッドは省略しています。

post：リクエストのメソッドが POST の場合の処理を実行する（ログアウト処理とレスポンス返却）
get_success_url：リダイレクト先の URL を取得する
get_context_data：テンプレートに渡すコンテキストを生成する
get_next_page：リダイレクト先の URL を取得する
get_template_names：テンプレートファイルの名前を取得する
render_to_response：レスポンスを返却する

ちなみに、ここまで説明してきたリダイレクト先の URL の取得は get_success_url メソッドによって行われます。なので、get_success_url をオーバーライドしてしまえば、前述で示した３つの方法以外の方法でリダイレクト先の URL を設定するようなことも可能となります。

`LogoutView` が生成するコンテキスト

続いて LogoutView が生成するコンテキストについて説明しておきます。

LogoutView は get_context_data メソッドの中でコンテキストを生成し、その生成するコンテキストには下記の要素が含まれます。

'site'：ログアウトしようとしているサイト（アプリ）の情報
'site_name'：ログアウトしようとしているサイト（アプリ）の名前（ドメイン名？）
'title'：'Logged out'
'sub_title'：None

基本的に LogoutView では「ログアウトしました」などのメッセージを表示するのみとなることが多いため、テンプレートファイルからコンテキストの要素を参照するようなことは少ないかもしれないですが、ログアウトしたサイト（アプリ）の情報等を表示したい場合は、上記のコンテキストを参照して出力してやっても良いと思います。

もし、他のデータをコンテキストにセットしてテンプレートファイルから参照できるようにしたいのであれば、ListView の解説ページの extra_context で説明しているクラス変数 extra_context を定義したり、get_context_data のオーバーライドを行なったりしてコンテキストの要素を追加することも可能です。

`LogoutView` の利用例

ページの冒頭でも少し説明したように、LogoutView の利用例に関しては下記ページの LoginView の利用例の中でまとめて紹介するようにしています。

【Django】LoginViewの使い方（クラスベースビューでのログインの実現）

上記ページでも説明している通り、ログイン機能を搭載するウェブアプリにおいては LogoutView だけでなく、LoginView や LoginRequiredMixin も適切に利用して実装していく必要があります。

まとめ

このページでは、LogoutView および LogoutView を継承したクラスベースビューの作り方について解説しました！

LogoutView はログアウトを実現するための View のサブクラス であり、このクラスを継承するビューを定義することで、ユーザーのログアウトが簡単に実現することができます。

ただし、ログアウトが必要になるのはログイン機能を備えたウェブアプリであり、ログイン機能を備えたウェブアプリを開発するために LoginView を継承するクラスや LoginRequiredMixin を継承するクラス等の定義も必要となります。そのため、LogoutView 単体で使い方を覚えておくというよりも、LoginView や LoginRequiredMixin もセットで使い方を覚えておく必要があります。

ログイン機能を実現できるようになれば開発可能なウェブアプリの幅が一気に広がります。そして、ログイン機能を実現するからにはログアウト機能も必要となりますので、是非 LogoutView を利用したビューの作り方についても覚えておいてください！

また、このサイトでは他の View のサブクラス についても説明していますので、他のページも是非読んでみてください！

【Django】ListViewの使い方（クラスベースビューでの一覧リストページの実現）