昨今のインターネットでは、SSLに対応していないWebページにアクセスするとブラウザから警告が出るようになっています。なので、Webページを公開する時は必ずSSLに対応するというのは最早常識の域になりつつあります。

しかし、SSLに対応しただけでユーザーがSSLと非SSLのどちらを選ぶかはまた別の話です。URLの先頭がhttps://かhttp://かでSSLと非SSLが振り分けられるようになっていますが、人によってはsを忘れてしまったりする事もあるかもしれませんし、その場合は普通にセキュリティの警告が出ます。

警告が出ないようにそもそもhttp://で公開しないという手もありますが、それだと上のようなケースではWebサイトが存在しない物として扱われてしまいます。

なので、http://を公開しながらアクセスの全てをhttps://にリダイレクトするのが良いと思います。

ついでに、SEO対策としてwwwの有無でページの評価が分散しないように、wwwの有無も統一します。

Webページを公開した最初しかやらなくて毎度忘れているので、自分用のメモとして残しておきます。

.htaccessファイルを作る

Webサイトのドキュメントルートに.htaccessを作成します。Wordpress等だと既に作ってあります。

これの先頭に、以下の内容を記述します。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

これでOKです。http://且つwww無しのURLへのアクセスが、https://且つwww有りのURLに転送されます。

解説

.htaccessに記述した内容を解説します。

URLの書き換えを行うモジュールを利用できる場合に、URL書き換えを有効化して<IfModule mod_rewrite.c>から</IfModule>までの間の処理を実行します。

<IfModule mod_rewrite.c>
RewriteEngine On
...
</IfModule>

http://のURLをhttps://のURLにする

上行が書き換えの条件、下行が書き換えの内容です。

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

SSLのアクセスではない場合に、URLの先頭をhttps://に書き換えます。

%{HTTP_HOST}と%{REQUEST_URI}はアクセスのあったURLに応じて以下のような文字列に置き換えられます。

URL = http://www.example.com/index.html?p=123
%{HTTP_HOST} = www.example.com
%{REQUEST_URI} = /index.html?p=123

https://%{HTTP_HOST}%{REQUEST_URI} -> https://www.example.com/index.html?p=123

末尾の[L,R=301]に関しては詳細を省きますが、リダイレクトが恒久的なリダイレクトであることを表します。

R=300とするとそのリダイレクトは一時的なものであると認識されます。

wwwを付ける

www無しのURLで運用している場合(https://kthksgy.com)や、サブドメインで運用している場合(https://subdomain.kthksgy.com)は以下の2行を省いてください。

上行は『ホスト名の先頭がwww.ではない場合』の条件を表します。

下行はhttps://の時と同じく書き換えを行います。

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule .* https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

環境

今回は、以下の環境で行いました。

• Ubuntu 18.04 LTS
• MariaDB 10.4.12

MariaDBモニターを開く

MariaDBモニターは、PythonやRubyのインタラクティブシェルのように、対話形式でSQLを実行出来るモードです。

# (Bash)
$ sudo mariadb

ユーザーの作成

MariaDBモニターで、create user 'ユーザー名'@'localhost' identified by 'パスワード';を行います。

MariaDB [(none)]> create user 'myuser'@'localhost' identified by 'mypassword';
Query OK, 0 rows affected (0.004 sec)

これで、ユーザーmyuserが作成され、mypasswordというパスワードで接続出来るようになりました。

データベースの作成

データベースの作成と言うと少々混乱するかも知れませんが、作成するのはMariaDBやMySQLではありません。MariaDB上に、WordPress専用の領域を設けるというニュアンスが近いです。一般的にリレーショナルデータベースと言うと、次のような構造になっていて、今から作成するのはデータベース1やデータベース2の部分です。

データベースソフトウェア(MariaDB, MySQL, PostgreSQL, ...)
|-- データベース1 (WordPress用)
   |-- テーブル1 (wp_posts)
      |-- レコード1 (初めましての記事)
   |-- テーブル2 (wp_comments)
   |-- ...
|-- データベース2 (個人的なデータ保存用)
|-- ...

MariaDBモニターで、create database DB名;を行います。

MariaDB [(none)]> create database mydatabase;
Query OK, 1 row affected (0.001 sec)

これで、MariaDB上にWordPressの記事やコメントを保存するための領域が確保されました。

ユーザーにデータベースの権限を付与

先ほど作成したユーザーに、先ほど作成したデータベースへの権限を付与します。MariaDBモニターで、grant ALL on データベース名.* to 'ユーザー名'@'localhost';を行います。

MariaDB [(none)]> grant ALL on mydatabase.* to 'myuser'@'localhost';
Query OK, 0 rows affected (0.001 sec)

MariaDBモニターを閉じる

exitで抜けられます。

MariaDB [(none)]> exit
Bye

WordPressとデータベースを接続する

後は、WordPressが公開されているURLにアクセスして、先ほど作ったユーザーでデータベースに接続します。

まとめ

今回はWordPressもMariaDBも同じサーバー上にあるので、MariaDB上でのユーザー作成から権限設定までの一連の流れで簡単に出来ました。

LiteSpeed Web Serverとは

第4のウェブサーバーと呼ばれる、nginxよりも更に効率的なウェブサーバーです。

高負荷時にnginxよりも高いパフォーマンスを発揮出来るようで、一部の共用サーバーではApacheやnginxの代わりにLiteSpeedを導入して「高速」を謳っている所も在ります。

環境

今回は、OpenLiteSpeedとLSPHPを使用しています。

• OpenLiteSpeed 1.6.7
• LSPHP 7.3

管理者ユーザーの作成

まずは管理者ユーザーを作成します。このユーザーを使って、管理コンソールに入れるようになります。LiteSpeedには管理者ユーザー作成用のシェルスクリプトが用意されているので、実行して従うだけです。

# (Bash)
$ sudo /usr/local/lsws/admin/misc/admpass.sh
[sudo] password for ...:

Please specify the user name of administrator.
This is the user name required to login the administration Web interface.

User name [admin]: ...

Please specify the administrator's password.
This is the password required to login the administration Web interface.

Password:
Retype password:
Administrator's username/password is updated successfully!

起動状態の確認

ユーザー作成が終わったら、ウェブサーバーの起動状態を確認します。

# (Bash)
$ sudo /usr/local/lsws/bin/lswsctrl status
litespeed is running with PID 10388.

このように、実行中のPIDが表示されたら既に起動されています。そうでない場合は以下のコマンドを実行して起動します。

# (Bash)
$ sudo /usr/local/lsws/bin/lswsctrl start

ページにアクセスしてみる

ここからは私の独自ドメインでURLを表記するので、適宜自分の環境で読み替えてください。例えば、ローカル環境ならhttp://lsws.devmem.infoはhttp://localhostみたいに。

デフォルトでは、http://lsws.devmem.info:8088にページが公開されています。

事前にファイアウォールの設定をしてポートを開放しているので、早速アクセスしてみます。

アクセス出来ました。次は、管理コンソールにアクセスしてみます。

管理コンソールは、https://lsws.devmem.info:7080に在ります。デフォルトでHTTPSで接続するようになっていますが、証明書が無いので危険な状態と表示されます。Chromeはセキュリティが厳しいのでアクセスすら出来ませんでした。なので、Edgeを使って接続します。

管理画面へのログインページが表示されました。ここに、先ほど作ったユーザーでログインします。

まずログインすると、ダッシュボードが表示されます。ここにアクセス統計情報等が表示されるようです。

WordPressの構築

デフォルトページも管理コンソールもログイン出来たのでここで終わりにしても良いのですが、せっかくLSPHPも導入しているのでWordPressを構築します。

Virtual Hostの設定

管理コンソール左のメニューから、「Virtual Hosts」を開いてください。

デフォルトでは、先ほど見たデフォルトページにアクセスするためのVirtual Hostが定義されています。

ここに別のVirtual Hostを追加する事で、複数サイトを1つのウェブサーバーで運営する事が可能になります。

リストの見出しの右にある追加ボタン(プラスマーク)から、新規にVirtual Hostを追加します。

今はWordPressを構築しているので、Virtual Host Nameはシンプルに「WordPress」で、Virtual Host Rootは適当に/usr/local/lsws/vhosts/WordPressになるように設定しました。

注意点としては、Virtual Host Rootは外部公開用のドキュメントルートではなくVirtual Hostのルートです。ここに外部公開用のドキュメントルートとしてhtmlディレクトリやログ保存用としてlogディレクトリを作成します。

Config Fileに関しては、$SERVER_ROOT/conf/vhosts/$VH_NAME/vhconf.confに設定するのが推奨されています。

External App Set UID ModeはServer UIDにします。これは、wp-config.php等を変更する時に権限の問題が起きないようにしてくれます。

見出し右の保存ボタンを押しましょう。

保存ボタンを押すと、設定ファイルが存在しない旨のエラーが表示されるので、エラー文の最後のCLICK TO CREATEを押して作成してもらいます。

再度保存ボタンを押すと、Virtual Hostsの一覧に戻って、WordPressというVirtual Hostが追加されている事が確認出来ます。

次に、Virtual Hostのドキュメントルートの設定を行います。

追加したWordPressの設定を開いて、Generalタブに進みます。

見出し右の編集ボタンをクリックしてください。

Document Rootには$VH_ROOT/htmlが推奨されているようです。編集し終えたら見出し右の保存ボタンから保存してください。

次に、Rewriteタブを開いて、Auto Load from .htaccessをYesに変更します。

WordPressはページのURLを.htaccessで制御しているので、この設定を行わないとトップページと管理ページ以外のページが404エラーになる状態になります。

Listenerの設定

リスナーは、アクセスされたURLに応じて、表示するページを分ける事が出来ます。

管理コンソール左のメニューから、Listenersを開いてください。

デフォルトではDefaultという名のListenerが1つだけ定義されているはずです。

画面上部ではListenerに関する設定が、画面下部ではこのListenerに紐づくVirtual Hostと対応するドメインが定義されています。

Defaultではポート8088番のアクセスをドメインに関係無くExampleに振り分けるように定義されています。

ではまず、ポート8088番ではなく、ポート80番で接続するようにします。見出し右の編集ボタンを押して編集します。例の如く、ポート開放等は既に行っています。

編集が終わったら、次は画面下部にあったVirtual Host Mappingsの設定です。Exampleは不要なので、Exampleの設定を編集します。

http://lsws.devmem.infoでのアクセスで構築中のWordPressを表示したいので、このように設定します。ワイルドカードにも対応していて、*.devmem.infoのような事も出来ます。

編集が終わったら保存してください。保存が終わったら、管理コンソール右上にあるLSWS PIDの表示の隣に在る、Graceful RestartボタンからLiteSpeedを再起動します。

WordPressのダウンロードと配置

先ほど設定したVirtual Host Rootディレクトリを作成します。

# (Bash)
$ sudo mkdir /usr/local/lsws/vhosts/WordPress

作成したら、WordPressをダウンロードして、設定したDocument Rootディレクトリに合うようにリネームします。また、WordPressからファイルの書き換えが生じた場合にDocument Rootディレクトリの所有者とファイルの所有者が異なると追加設定が必要になるので修正します。デフォルトではユーザーnobody、グループnogroupとして書き換えが実行されるようなので、chown -Rで再帰的に変更します。

# (Bash)
# Virtual Host Rootへ移動
cd /usr/local/lsws/vhosts/WordPress
# WordPressのダウンロード sudo curl -o - https://ja.wordpress.org/latest-ja.tar.gz | sudo tar xzvf -
# リネーム
sudo mv wordpress html
# 所有権の設定 sudo chown -R nobody:nogroup WordPress/

これで、WordPressの配置が完了しました。

確認する

では、http://lsws.devmem.infoにアクセスしてみます。

無事に、お馴染みのWordPressの初期設定画面が表示されました。

まとめ

第4のウェブサーバーと呼ばれるLiteSpeed Web ServerでWordPressを構築しました。

今まで、ウェブサーバーは共用サーバーに備えついているApacheやnginxを使っていたので、ウェブサーバー自体の構築は初めてしましたが、管理コンソールのおかげで設定が見易くて助かりました。

nginxと比較してどうかは分かりませんが、アクセスはサクサクなので満足しています。

参考

• Setting up Name-based Virtual Hosting on OpenLiteSpeed – OpenLiteSpeed
• How To Install the OpenLiteSpeed Web Server on Ubuntu 18.04 | DigitalOcean
• Ubuntu 18.04 LTS に WordPress 5.3 をインストール

LAMP環境とは

OS、Webサーバー、データベース、プログラミング言語からなる環境の事です。以下の構成が最もメジャーな環境だったため、その頭文字を取ってLAMP環境と呼ばれるようになりました。

• Linux
• Apache
• MySQL
• PHP

一般に、これら以外の構成からなる環境も、LAMP環境と呼ばれるようです。

環境

VPS上で構築します。

• Ubuntu 18.04 LTS

L(Linux)

VPSのインスタンスを立ち上げた時に既にインストールされているので、省略します。

A(OpenLiteSpeed)

今回は、ApacheではなくOpenLiteSpeedを用います。以下のコマンドで、OpenLiteSpeedをaptでインストール出来るようにします。

# (Bash)
curl -o - https://rpms.litespeedtech.com/debian/lst_repo.gpg | sudo apt-key add - sudo add-apt-repository 'deb http://rpms.litespeedtech.com/debian/ bionic main'

その後、以下のコマンドでインストールします。

# (Bash)
$ sudo apt install openlitespeed

M(MariaDB)

今回は、MySQLではなくMariaDBを用います。以下のコマンドで、最新のMariaDBをaptでインストール出来るようにします。

# (Bash)
$ curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

このコマンドを実行すると、/etc/apt/sources.list.d/mariadb.listが生成されます。最新版以外のMariaDBを利用したい場合は、mariadb-10.4等、この中のバージョンを書き換えます。

# MariaDB Server
# To use a different major version of the server, or to pin to a specific minor version, change URI below.
deb http://downloads.mariadb.com/MariaDB/mariadb-10.4/repo/ubuntu bionic main

# MariaDB MaxScale
# To use the latest stable release of MaxScale, use "latest" as the version
# To use the latest beta (or stable if no current beta) release of MaxScale, use "beta" as the version
deb http://downloads.mariadb.com/MaxScale/2.4/ubuntu bionic main

# MariaDB Tools
deb http://downloads.mariadb.com/Tools/ubuntu bionic main

次に、インストール可能なMariaDBのパッケージを検索します。

# (Bash)
$ sudo apt list | grep -i mariadb-server
mariadb-server/unknown 1:10.4.12+maria~bionic all
mariadb-server-10.1/bionic-updates,bionic-security 1:10.1.43-0ubuntu0.18.04.1 amd64
mariadb-server-10.4/unknown 1:10.4.12+maria~bionic amd64
mariadb-server-core-10.1/bionic-updates,bionic-security 1:10.1.43-0ubuntu0.18.04.1 amd64
mariadb-server-core-10.4/unknown 1:10.4.12+maria~bionic amd64

mariadb-server-10.4とmariadb-server-10.1が利用出来るようです。今回はMariaDB 10.4をインストールします。

# (Bash)
$ sudo apt install mariadb-server-10.4

インストールが終わったら、一度実行して確認します。

$ sudo mariadb
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is ..
Server version: 10.4.12-MariaDB-1:10.4.12+maria~bionic-log mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> exit
Bye

これでMariaDBのインストールは完了です。

P(LSPHP)

今回は、通常のPHPではなくLiteSpeed用のPHPを用います。

デフォルトでOpenLiteSpeedは同時インストールされるLSPHP 7.3を使用するようになっています。

ただ、FastCGIから利用する場合はLSPHP 5になるようなので、此方もLSPHP 7.3を使うように変更します。

OpenLiteSpeedはFastCGIモードでの実行時に/usr/local/lsws/fcgi-bin/lsphpを呼び出していて、デフォルトでは同じディレクトリにあるlsphp5にリンクが貼ってあるようです。なので、このファイルに対してLSPHP 7.3へのソフトリンクを作ります。

# (Bash)
$ sudo ln -sf /usr/local/lsws/lsphp73/bin/lsphp /usr/local/lsws/fcgi-bin/lsphp

LSPHPのバージョンを変更する場合

通常この操作は必要無いですが、デフォルトでインストールされるバージョン以外のバージョンを使いたい場合は以下の通りにしてください。

インストールに必要なリポジトリの登録はOpenLiteSpeedのインストール時に済んでいるので、aptでインストール出来ます。

まず、インストール可能なLSPHPのパッケージを検索します。出力が長いのでここには貼りません。

# (Bash)
$ sudo apt list | grep -i lsphp
...

lsphp70～lsphp74がインストール出来るようです。今回はLSPHP 7.4をインストールします。

# (Bash)
$ sudo apt install lsphp74

インストールが終わったら、LiteSpeedの管理コンソールからServer Configurationを開き、External AppタブにあるLiteSpeed SAPI AppのCommand設定を書き換えてください。

まとめ

これで、第4のウェブサーバーと呼ばれるLiteSpeedを軸にした新しめなLAMP環境が構築出来ました。

今回はインストールのみですが、実際に利用する際はLiteSpeedの管理コンソールで様々な設定が必要になります。

参考

• How To Install the OpenLiteSpeed Web Server on Ubuntu 18.04 | DigitalOcean
• Ubuntu 18.04 LTS に MariaDB 10.4 をインストール

Djangoバックエンドの準備

ログインとログアウトをトークン認証で行うために修正を行います。

Django REST Framework JWTのインストール

デフォルトのdjango-rest-authでもトークン認証はされているのですが、これをJWT版のトークン認証に変更します。

専用のパッケージが用意されていて、これをインストールして設定する事でdjango-rest-authがJWTを利用するようになります。

$ pip install djangorestframework-jwt

blogress/settings.pyを変更します。ついでにメールアドレス認証にも変更します。

# 追記
ACCOUNT_AUTHENTICATION_METHOD = 'email'
ACCOUNT_EMAIL_REQUIRED = True   
ACCOUNT_USERNAME_REQUIRED = False

REST_USE_JWT = True # 追記

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAuthenticated',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [
        'rest_framework_jwt.authentication.JSONWebTokenAuthentication', # 変更
    ],
    'NON_FIELD_ERRORS_KEY': 'detail', # 変更
    'TEST_REQUEST_DEFAULT_FORMAT': 'json' # 変更
}

ルーティングの修正

また、特に理由は無いですがルーティングも少し変更しておきます。

from django.contrib import admin
from django.urls import include, path
from rest_framework.schemas import get_schema_view
from django.views.generic import TemplateView

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/posts/', include('posts.urls')),
    path('api/users/', include('users.urls')),
    path('api/auth/', include('rest_auth.urls')),
    path('api/auth/register/', include('rest_auth.registration.urls')),
    path('schema/', get_schema_view( # スキーマ表示の追加
        title="Blogress",
        description="API for all things …"
    ), name='openapi-schema'),
    path('docs/', TemplateView.as_view( # ドキュメント表示の追加
        template_name='swagger-ui.html',
        extra_context={'schema_url':'openapi-schema'}
    ), name='swagger-ui'),
]

これで、DjangoバックエンドのJWTでのトークン認証の準備が整いました。

Reactフロントエンドの準備

トークン認証なのでバックエンドからトークンが送られてくるわけですが、それをReactで上手く扱えるようにします。

Redux

Reduxは状態管理を行ってくれるフレームワークです。

これがあるとReactが管理するデータが膨大になった時にpropsでデータを親から子へバケツリレーしなくて良くなるようです。

今回はReduxを使って、得られたトークンを保持します。

Redux-Thunk

Redux-ThunkはReduxの機能を非同期的に行ってくれるライブラリです。

トークン取得等の通信を要する処理結果をReduxで管理する場合に必要になるようです。

ReduxとRedux-Thunkのインストール

ReduxとRedux-Thunkをインストールして、ReactとReduxの連携を補助するReact-Reduxをインストールします。

$ npm install redux
$ npm install react-redux
$ npm install redux-thunk

React-Router-DOM

React-Router-DOMはReactのURLとDOMを関連付けてくれるライブラリです。

これを使って、ログインページとトップページのルーティングを行います。

React-Router-DOMのインストール

下記コマンドでインストールを行います。

$ npm install react-router-dom

リファクタリング

これまで書いて来たフロントエンドのコードが少々気になり始めたので、ログインページを作る前にリファクタリングを行います。

まず初めにfrontend/src/App.jsです。

全てのコンポーネントの最上位に位置しているので、ここでは各ページへのルーティングと、ストアやAxiosインスタンス等アプリ内で唯一の物の作成をします。

ついでにfrontend/src/App.jsxにリネームして、frontend/src/components/constants.jsxの内容も統合しましょう。

まだページは作成していませんが、ログインページをfrontend/src/components/pages/LoginPage.jsxに作ることにしてルーティングを先にします。

/**
 * src/App.jsx
 * @file ルーティングやシングルトン定義をする最上位コンポーネント
 */
import React from 'react';
import { BrowserRouter, Route, Switch } from 'react-router-dom';
import Axios from 'axios';

/* Redux関連 */
import { createStore } from 'redux';
import { Provider } from 'react-redux';
import reducer from './modules';

/* ページコンポーネント */
import TopPage from './components/pages/TopPage';
import LoginPage from './components/pages/LoginPage';

/**
 * ブログタイトル
 * @type {string}
 */
export const title = 'My Blogress Life';
/**
 * ブログの説明
 * @type {string}
 */
export const description = 'This is my blog made in simple blog system named Blogress.';
/**
 * コピーライト表示
 * @type {string}
 */
export const copyright = 'Copyright © ' + title + ' ' + new Date().getFullYear() + '.';

/**
 * APIエンドポイント
 * @type {string}
 */
export const endpoint = 'http://localhost:8000/api';

/** Redux用のストア */
export const store = createStore(reducer);

/** ベースのURLが定義されたAxiosインスタンスを作成して使い回す */
export const axios = Axios.create({
  baseURL: endpoint,
  timeout: 1000,
  headers: { "Content-Type": "application/json" },
  data: {},
  responseType: 'json',
});

/* 各ページのルーティング */
const App = () => {
  return(
    <Provider store={store}>
      <BrowserRouter>
        <Switch>
          <Route exact path='/login' component={LoginPage}/>
          <Route exact path='/' component={TopPage}/>
        </Switch>
      </BrowserRouter>
    </Provider>
  );
}

export default App;

ブログタイトルを保持するファイルが変わったので、frontend/src/components/organisms/Header.jsxを修正します。

/**
 * src/components/organisms/Header.jsx
 * @file ヘッダーを表示するコンポーネント
 */
import React, { Fragment } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import { AppBar, Toolbar, Typography } from '@material-ui/core';
import SportsVolleyballIcon from '@material-ui/icons/SportsVolleyball';

import { title } from '../../App';

const useStyles = makeStyles(theme => ({
    offset: theme.mixins.toolbar,
}))

const Header = () => {
    const classes = useStyles();
    return(
        <Fragment>
            <AppBar position='fixed'>
                <Toolbar>
                    <SportsVolleyballIcon />
                    <Typography variant="h6" color="inherit" noWrap>
                        {title}
                    </Typography>
                </Toolbar>
            </AppBar>
            <div className={classes.offset}/>
        </Fragment>
    );
}

export default Header;

コピーライトの文字列も一元化したので、表示するコンポーネントもfrontend/src/components/atoms/Copyright.jsxを作成します。

/**
 * src/components/atoms/Copyright.jsx
 * @file 著作権表示をするコンポーネント
 */
import React from 'react';

import { Typography } from '@material-ui/core';

import { copyright } from '../../App';

const Copyright = () => (
    <Typography variant="body2" color="textSecondary" align="center">
        {copyright}
    </Typography>
);

export default Copyright;

元々コピーライト表示をしていたfrontend/src/components/organisms/Footer.jsxも修正します。

/**
 * src/components/organisms/Footer.jsx
 * @file フッターの表示をするコンポーネント
 */

import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

import Copyright from '../atoms/Copyright';

const useStyles = makeStyles(theme => ({
    footer: {
        backgroundColor: theme.palette.background.paper,
        padding: theme.spacing(6),
    },
}))

const Footer = () => {
    const classes = useStyles();
    return(
        <footer className={classes.footer}>
            <Copyright />
        </footer>
    );
}

export default Footer;

Axiosのインスタンスを作成して使い回すようにしたので、frontend/src/components/pages/TopPage.jsxのAxiosがインスタンスを読み込むように修正します。

/**
 * src/components/pages/TopPage.jsx
 * @file トップページを表示するコンポーネント
 */
import React, { useState, useEffect } from 'react';
import { axios } from '../../App';
import { makeStyles } from '@material-ui/core/styles';

import TopPageTemplate from '../templates/TopPageTemplate';

const useStyles = makeStyles(theme => ({
    page: {
        margin : 60,
    }
}));

const TopPage = () => {
    const classes = useStyles();
    const [posts, setPosts] = useState([]);

    useEffect(() => {
        axios
            .get('/posts/', )
            .then(res=>{setPosts(res.data);})
            .catch(err=>{console.log(err);});
    }, []);

    return(
        <TopPageTemplate className={classes.page} posts={posts} />
    );
}

export default TopPage;

ログインページを作る

シンプルなログインページを作ります。

まずは、ログイン用のフォームを作成します。

これは後々トップページでも小さく開けるように、frontend/src/components/organisms/LoginForm.jsxに作成します。

/**
 * src/components/organisms/LoginForm.jsx
 * @file ログイン時の入力パネルを表示するコンポーネント
 */

import React, { useState } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import { Box, TextField, Button, Checkbox, FormControlLabel, Typography } from '@material-ui/core'
import InputIcon from '@material-ui/icons/Input';

const useStyles = makeStyles(theme => ({
    form: {
        width: '100%',
        marginTop: theme.spacing(1),
    },
    button: {
        width: '100%',
        marginTop: theme.spacing(1),
    },
    checkbox: {
        float: 'right',
    }
}));

const LoginForm = props => {
    const classes = useStyles();
    const [email, setEmail] = useState('');
    const [password, setPassword] = useState('');
    const [showPassword, setShowPassword] = useState(false);
    return (
        <Box width={256} p={6} border={1}>
            <Typography component="h1" variant="h5">ログイン</Typography>
            <form noValidate>
                <TextField className={classes.form} id="emailForm"
                    value={email} onChange={e => setEmail(e.target.value)}
                    label="メールアドレス"/>
                <TextField className={classes.form} id='passwordForm'
                    value={password} onChange={e => setPassword(e.target.value)}
                    label="パスワード"
                    type={showPassword ? '' : 'password'}
                    autoComplete='current-password'/>
                <FormControlLabel className={classes.checkbox} label="パスワードを表示" control={
                    <Checkbox
                        checked={showPassword}
                        onChange={e => setShowPassword(e.target.checked)}
                        value="primary"
                        inputProps={{ 'aria-label': 'primary checkbox' }}/>
                }/>
                <Button className={classes.button}
                    variant='contained' color='primary' startIcon={<InputIcon />} onClick={e=>props.login(email, password)}>ログイン</Button>
            </form>
        </Box>
    );
}

export default LoginForm;

そしてこれを使ってログインページのテンプレートを作ります。

/**
 * src/components/templates/LoginPageTemplate.jsx
 * @file ログインページのテンプレートコンポーネント
 */
import React, { Fragment } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import Footer from '../organisms/Footer';
import LoginForm from '../organisms/LoginForm';

const useStyles = makeStyles(theme => ({
    content: {
        display: 'flex',
        justifyContent: 'center',
        marginTop: theme.spacing(4),
    }
}));

const LoginPageTemplate = props => {
    const classes = useStyles();
    return (
        <Fragment>
            <div className={classes.content}>
                <LoginForm login={props.login}/>
            </div>
            <Footer />
        </Fragment>
    );
}

export default LoginPageTemplate;

このテンプレートに対して、実際にログインを行う関数をpropsで渡す事で、frontend/src/components/pages/LoginPage.jsxにページを作ります。

/**
 * src/components/pages/LoginPage.jsx
 * @file ログインページ
 */

import React from 'react';
import { axios } from '../../App';

import { useSelector, useDispatch } from 'react-redux';

import { setToken } from '../../modules/UserModule';

import LoginPageTemplate from '../templates/LoginPageTemplate';

const LoginPage = () => {
    const dispatch = useDispatch();
    const token = useSelector(state => state.user.token);

    const login = (email, password) => {
        axios
            .post('/auth/login/', {
                email: email,
                password: password,
            })
            .then(res=>{dispatch(setToken(res.data.token));axios.defaults.headers.common['Authorization'] = 'JWT ' + token;})
            .catch(err=>{console.log(err);});
    }
    return (
        <LoginPageTemplate login={login}/>
    );
}

export default LoginPage;

これで、http://localhost:3000/loginにアクセスするとログイン画面が表示されたはずです。

実際にログイン出来たか確認する実装していないので、ここはブラウザのデバッグ機能でどういうResponseが返って来たのかを見ましょう。

ChromeではF12キーで開けて、メールアドレスとパスワードに関わらずログインを押すと、Networkのタブに何かしらの結果が出て来るはずです。

ステータスコード200で、tokenがJSON形式で返って来ていれば完了です。

認証トークンをヘッダに付与する

JSON Web Tokenでの認証は、HTTPヘッダにAuthorizationとして受け取ったトークンを設定する事で実現出来ます。

具体的には以下のようなヘッダを付与します。

{
  "header": {
    "Content-Type": "application/json"
    "Authorization": "JWT TTTTOOOOKKKKEEEENNNN"
  },
  "data": {},
}

上記のコードはJWTを取得したと同時にAxiosのヘッダにAuthorizationとして付与するようにしているので、既に認証状態で通信が可能です。

具体的には、axios.defaults.headers.common['Authorization'] = 'JWT ' + token;でデフォルト設定を行っています。

まとめ

とりあえずJWTでのトークンの受け取りと認証が出来るようになりました。

現在はバックエンド側の権限設定を適当にやっているので、Django REST Frameworkについて理解を深めて適切に設定したいです。

参考

• Hooks・React Redux
• react-hooks で redux を書いてみた話
• 挫折しないで！作って学ぶ React + Redux 入門【実践】

モックアップを作る

まず初めに、ページのモックアップを作ります。

モックアップとは、工業製品の設計・デザイン段階で試作される、外見を実物そっくりに似せて作られた実物大の模型のこと。ソフトウェアやWebサイト、印刷物などのデザインを確認するための試作品のこともこのように呼ばれることがある。

――― IT用語辞典 e-Words

作ろうと思いましたが、この手のモックアップツールは大半が有料みたいなのでペイントで済ませます。

出来ました。シンプルな2カラム右サイドバーのトップページです。

少々荒は目立ちますが、こんな感じで作るページのイメージを画像にしておきます。

ヘッダーは左側にブログのヘッダー画像かブログアイコンとブログタイトルが表示され、右側にドロップダウンメニューやリンクが表示されます。

それぞれの記事はアイキャッチ画像の上にタイトルと概要が表示されます。

サイドバーはまだ何を置くか決めていませんが、ウィジェット形式の何かが作成出来ると良いと思います。

Atomic Design とは

ウェブページを構成する要素を粒度を基準に分類する事で、要素の再利用性の向上や冗長性の削減を目指すという思想らしいです。

要素ベースでページを作るReact等の最近のフロントエンドフレームワークでウェブアプリケーションを作成する場合に役に立ちます。

分類は5つ有り、それぞれに以下のような名前と基準が付いています。

• Atoms (原子) : それ以上分割出来ない要素
• Molecules (分子) : 2つ以上の原子から構成される要素
• Organisms (有機体) : いくつかの分子の集合
• Templates (テンプレート) : データを流し込むための枠組み
• Pages (ページ) : 実際のデータを含むテンプレート

実際にどのような要素が分類されるのかをメモしておきます。

入力フォームは入力のためテキストボックスや送信のためボタン等のAtomの集合なのでMolecule、ヘッダーは様々なアイコン付きボタンや見出しテキストドロップダウンメニューから成り立っているのでOrganismsという感じのようです。

少々難しいですが、ウェブ開発を効率化するための思想に捕らわれて効率が落ちるのは本末転倒なので、あまり深くは考えずこの思想に緩く制約されようと思います。

ちなみに、Atomic Designに階層構造を取り入れたLayered Atomic Designという物もあるようです。

Reactでフロントエンドを作る

では、実際に作っていきます。

Material-UIのインストール

作り始める前に、React用のUIフレームワークの1つであるMaterial-UIをインストールします。

$ cd frontend
$ npm install @material-ui/core @material-ui/icons

コマンドを使って暫く待つとインストール完了です。

Atomic Designのためのディレクトリ構造を作る

前回は、ページを構成する要素を全てfrontend/src/App.jsに記述しました。

Atomic Designでは要素に対し分類がされているので、まずはそれぞれのディレクトリを作成します。

まずは要素を保存するための親ディレクトリをfrontend/src/components/に作成します。

そしてその中に、atoms、molecules、organisms、templates、pagesのディレクトリをそれぞれ作ります。

具体的には、以下のようなディレクトリ構造になります。

blogress/
|-- frontend
   |-- src/
      |-- components/
         |-- atoms/ (原子)
         |-- molecules/ (分子)
         |-- organisms/ (有機体)
         |-- templates/ (テンプレート)
         |-- pages/ (ページ)
   |-- ...
|-- ...

これらのディレクトリに適した物を書く事で、Reactのコンポーネント志向なウェブアプリケーション作成が自然と出来ます。

定数ファイルを作る

定数用のファイルを作る設計が良いのかは置いておいて、定数を置いておくためにfrontend/src/components/constants.jsxを作成してブログ名等を記述しておきます。

export const BLOG_TITLE = 'My Blogress Life';
export const BLOG_DESCRIPTION = 'This is my blog made in simple blog system named Blogress.'

将来的にはこれをAPIから読み込む形にするので、このように一ヶ所から参照する形にするようにしておくと恐らく便利です。

ヘッダーを作る

何処から作っても良いのですが、まずはヘッダーから作る事にします。

ReactはReactコンポーネントと呼ばれる要素単位を併せてページを作成するので、ヘッダーのReactコンポーネントを作成します。

frontend/src/components/organisms/Header.jsxに以下のように記述してください。

import React, { Fragment } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import { AppBar, Toolbar, Typography } from '@material-ui/core';
import SportsVolleyballIcon from '@material-ui/icons/SportsVolleyball';

import { BLOG_TITLE } from '../constants';

const useStyles = makeStyles(theme => ({
    offset: theme.mixins.toolbar,
}))

const Header = () => {
    const classes = useStyles();
    return(
      <Fragment>
        <AppBar position='fixed'>
            <Toolbar>
                <SportsVolleyballIcon />
                <Typography variant="h6" color="inherit" noWrap>
                    {BLOG_TITLE}
                </Typography>
            </Toolbar>
        </AppBar>
        <div className={classes.offset}/>
      </Fragment>
    );
}

export default Header;

今の所は特に何の機能も無い、ブログタイトルと謎のアイコンだけが存在している簡易なヘッダーです。

Atomic Designでファイル分割を行う

ヘッダーが完成したので早速トップページに設置して確認したい所ですが、ヘッダーのReactコンポーネントを利用する前に、frontend/src/App.jsの中身をAtomic Designに従って分割します。

オレオレAtomic Designかも知れませんが、frontend/src/App.jsを以下のように分割します。

frontend/src/components/templates/TopPageTemplate.jsxでは、トップページの骨組みを作成します。

import React, { useState, Fragment } from 'react';

import Header from '../organisms/Header';

const TopPageTemplate = props => (
    <Fragment>
        <Header />
        {props.posts.map(post => (
            <div key={post.id}>
            <h1>{post.title}</h1>
            <p>{post.body}</p>
            </div>
        ))}
    </Fragment>
);

export default TopPageTemplate;

このテンプレートに対して、frontend/src/components/pages/TopPage.jsxがブログの記事データをpropsで流し込むような構造にします。

import React, { useState, useEffect } from 'react';
import axios from 'axios';

import { makeStyles } from '@material-ui/core/styles';

import TopPageTemplate from '../templates/TopPageTemplate';

const useStyles = makeStyles(theme => ({
    page: {
        margin : 60,
    }
}));

const TopPage = () => {
    const classes = useStyles();
    const [posts, setPosts] = useState([]);

    useEffect(() => {
        axios
            .get('http://localhost:8000/api/posts/')
            .then(res=>{setPosts(res.data);})
            .catch(err=>{console.log(err);});
    }, []);

    return(
        <TopPageTemplate className={classes.page} posts={posts} />
    );
}

export default TopPage;

従って、frontend/src/App.jsでは以下のようにfrontend/src/components/pages/TopPage.jsxの表示のみを行います。

import React from 'react';

import TopPage from './components/pages/TopPage';

const App = () => {
  return(
    <TopPage />
  );
}

export default App;

多少オレオレAtomic Designな気がしますが、これが正しいと言い聞かせながら進みます。

では、http://localhost:3000/にアクセスして確認しましょう。

きちんとヘッダーが付いているのが確認出来ました。

記事タイルグリッドを作る

そのまま記事の一覧表示も作ります。

私のイメージを図にしたモックアップの通り、今回は記事タイルがグリッド表示されている物を作ります。

まずは、Atomic Designに従って、frontend/src/components/PostTile.jsxに単体の記事タイルを作ります。

import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

import { Card, CardActionArea, CardContent, CardMedia, Typography } from '@material-ui/core';

const useStyles = makeStyles({
  card: {
    position: 'relative',
    maxWidth: 345,
  },
  media: {
    height: 345
  },
  content: {
    position: 'absolute',
    bottom: 0,
    width: '100%',
    color: 'white',
    backgroundColor: 'rgba(0,0,0,0.6)',
  },
  excerpt: {
      marginRight: 30,
  }
});

const PostTile = props => {
    const classes = useStyles();
    return (
        <Card className={classes.card}>
          <CardActionArea>
            <CardMedia
              className={classes.media}
              image={props.thumbnail}
              title={props.title}
            />
            <CardContent className={classes.content}>
              <Typography gutterBottom variant="h5" component="h2">
                {props.title}
              </Typography>
              <Typography variant="body2" component="p" className={classes.excerpt} noWrap>
                {props.body}
              </Typography>
            </CardContent>
          </CardActionArea>
        </Card>
      );
}

export default PostTile;

そして、記事タイルグリッドはこの記事タイルを複数用いた物なので、frontend/src/components/organisms/PostTileGrid.jsxに作成します。

import React from 'react';

import { Grid } from '@material-ui/core'

import PostTile from '../molecules/PostTile';

const PostTileGrid = props => (
    <Grid container spacing={4}>
        {props.posts.map(post => (
            <Grid item xs={4}>
                <PostTile title={post.title} body={post.body} thumbnail={post.thumbnail}/>
            </Grid>
        ))}
    </Grid>
);

export default PostTileGrid;

PostTileGridが完成したので、frontend/src/components/templates/TopPageTemplate.jsxで利用するように書き換えます。

import React, { Fragment } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import Header from '../organisms/Header';
import PostTileGrid from '../organisms/PostTileGrid';

const useStyles = makeStyles(theme => ({
    postTileGrid: {
        margin: theme.spacing(4),
    }
}));

const TopPageTemplate = props => {
    const classes = useStyles();
    return (
        <Fragment>
            <Header />
            <div className={classes.postTileGrid}>
                <PostTileGrid posts={props.posts}/>
            </div>
        </Fragment>
    );
}

export default TopPageTemplate;

また、このままでは左右の余白がギリギリまで詰められてしまうので、frontend/src/index.cssを編集して、bodyにmin-width: 960px;を追加します。

body {
  margin: 0;
  font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Roboto', 'Oxygen',
    'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', 'Helvetica Neue',
    sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  min-width: 960px;
}

code {
  font-family: source-code-pro, Menlo, Monaco, Consolas, 'Courier New',
    monospace;
}

これで、記事がタイル状でグリッド表示されるようになったはずです。

サムネイル表示にも対応しているため、Djangoの管理画面からpostsのthumbnailを設定しながら、今は3つしかないサンプル記事をもう少し増やしてから確認します。

これまで見て来た質素な記事リストから、リッチな記事タイルグリッドになったのが確認出来たと思います。

また、frontend/src/index.cssでページの最低幅を指定しているので、横幅が小さくなりすぎても表示が崩れないようになっています。

フッターを作る

最後にフッターを作りましょう。

frontend/src/components/organisms/Footer.jsxを作成してください。

import React from 'react';
import { makeStyles } from '@material-ui/core/styles';

import { Typography } from '@material-ui/core';

import { BLOG_TITLE } from '../constants';

function Copyright() {
    return (
        <Typography variant="body2" color="textSecondary" align="center">
            {'Copyright © '}{BLOG_TITLE}{' '}{new Date().getFullYear()}{'.'}
        </Typography>
    );
}

const useStyles = makeStyles(theme => ({
    footer: {
        backgroundColor: theme.palette.background.paper,
        padding: theme.spacing(6),
    },
}))

const Footer = () => {
    const classes = useStyles();
    return(
        <footer className={classes.footer}>
            <Copyright />
        </footer>
    );
}

export default Footer;

フッターのReactコンポーネントが完成したので、frontend/src/components/templates/TopPageTemplate.jsxで利用しましょう。

import React, { Fragment } from 'react';
import { makeStyles } from '@material-ui/core/styles';

import Header from '../organisms/Header';
import Footer from '../organisms/Footer';
import PostTileGrid from '../organisms/PostTileGrid';

const useStyles = makeStyles(theme => ({
    postTileGrid: {
        margin: theme.spacing(4),
    }
}));

const TopPageTemplate = props => {
    const classes = useStyles();
    return (
        <Fragment>
            <Header />
            <div className={classes.postTileGrid}>
                <PostTileGrid posts={props.posts}/>
            </div>
            <Footer />
        </Fragment>
    );
}

export default TopPageTemplate;

これで、記事タイルグリッドの後に今の所コピーライトの表示だけしてくれるフッターが表示されるはずです。

記事が作成日時で昇順になっていたりと気になる点は有りますが、完成です。

まとめ

今回で一応なブログのトップページのような形になりました。

成果が目で確認しやすいフロントエンドはやっていて楽しいですね。

参考

• Installation – Material-UI
• App Bar React component – Material-UI
• Grid component – Material-UI
• Atomic Designを使ってReactコンポーネントを再設計した話
• アトミックデザイン

2020/11/09: コメントで頂いた修正をしました。ありがとうございます。

Djangoでバックエンドを作る

前回でREST Frameworkの基礎は完成したのですが、Reactとリソースを共有するためにはCORSというものを実現する必要があります。

CORSの実装

CORSはHTTP通信にCORSヘッダーを含める事で実装出来るのですが、Djangoではdjango-cors-headersというパッケージを導入して設定するだけで、簡単にCORSが実装出来ます。

$ pip install django-cors-headers

例の如く、新たなアプリをblogress/settings.pyにて登録しましょう。

INSTALLED_APPS = [
    # ローカルアプリ
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig',

    # サードパーティアプリ
    'rest_framework',
    'rest_framework.authtoken',
    'corsheaders', # 追記
    'allauth',
    'allauth.account',
    'allauth.socialaccount',
    'rest_auth',
    'rest_auth.registration',

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.sites',
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware', # 追記
    'django.middleware.common.CommonMiddleware', # 追記
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

# 追記
CORS_ORIGIN_WHITELIST = [
    'http://localhost:3000'
]

これでReactとの連携準備はバッチリです。

Reactでフロントエンドを作る

では、フロントエンドを作っていきます。

Reactのインストール

Node.jsのインストールについては事前に行っているので、npmコマンドが使える状態からのスタートです。

# Reactのインストール
$ npm install -g create-react-app

Reactプロジェクトの作成

Djangoプロジェクトのルートディレクトリ/blogress/にて、create-react-appでプロジェクトを開始します。

$ npx create-react-app frontend

完了すると、以下のようなディレクトリツリーになるはずです。

blogress/ (ルートディレクトリ)
|-- blogress/
|-- frontend/
|-- posts/
|-- templates/
|-- users/
|-- db.sqlite3
|-- manage.py

きちんとインストール出来たか確認するため、Reactのサーバーを立ち上げてみます。

$ cd frontend
$ npm start
# http://localhost:3000 にアクセスして確認

もしかしたら自動でブラウザが立ち上がるかもしれません。

無事立ち上がったようです。何故かEdgeでは見られなかったのでChromeで見ています。

ページの作成

ではAPIから実際にデータを受け取る前に、まずは仮データを用意してそれをページ上に表示させてみます。

Reactサーバーが実際に描画しているページはfrontend/src/App.jsにあります。

import React, { Fragment } from 'react';

const App = () => {
  const posts = [
    {
      id: 1,
      title: "仮データ1",
      description: "仮テキストです。"
    },
    {
      id: 2,
      title: "仮データ2",
      description: "仮テキストです。仮テキストです。"
    },
    {
      id: 3,
      title: "仮データ3",
      description: "仮テキストです。仮テキストです。仮テキストです。"
    }
  ]

  return(
    <Fragment>
      {posts.map(post => (
        <div key={post.id}>
          <h1>{post.title}</h1>
          <p>{post.description}</p>
        </div>
      ))}
    </Fragment>
  );
}

export default App;

このように変更すると、サーバーを立ち上げている場合は自動で再読み込みしてもらえます。

上手く行くと、このように3つ作った仮データがその説明と共に描画されます。

Axiosのインストール

Axiosは、ReactでREST APIへのリクエスト処理を実装するためのライブラリです。

React同様にこちらもnpmコマンドでインストールします。

$ npm install axios

REST APIの利用

Axiosをインストールし終えたので、REST APIからデータを受け取る事が出来るようになりました。

frontend/src/App.jsに書いていた仮データを実際のREST APIからのデータ取得に置き換えます。

import React, { Fragment, useState, useEffect } from 'react';
import axios from 'axios';

const App = () => {
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    axios
    .get('http://localhost:8000/api/posts/')
    .then(res=>{setPosts(res.data);})
    .catch(err=>{console.log(err);});
  }, []);

  return(
    <Fragment>
      {posts.map(post => (
        <div key={post.id}>
          <h1>{post.title}</h1>
          <p>{post.description}</p>
        </div>
      ))}
    </Fragment>
  );
}

export default App;

では、サーバーを起動しましょう。

この時、Djangoサーバーも立ち上げるのを忘れないように気を付けます。

ターミナルを2つ用意して、それぞれのサーバーを立ち上げてください。

# Djangoサーバーの起動
$ python manage.py runserver

# Reactサーバーの起動
cd frontend npm start

どちらも起動したら、http://localhost:3000にアクセスして確認しましょう。

無事にデータが受信出来ているようです。

まとめ

DjangoとReactの簡単な連携が取れるようになってかなり嬉しいです。

Reactの新機能「React Hooks」を使う事でコードがシンプルになりました。

参考

• Django REST Framework の使い方メモ
• チュートリアル：React の導入
• ステートフックの利用法

Djangoでバックエンドを作る

前回の続きから作ります。

Django REST Frameworkのインストール

以下のコマンドでインストールします。

# バージョン確認
python -V
Python 3.7.4

# Django REST Frameworkのインストール pip install djangorestframework

REST Frameworkの登録

Django REST Frameworkもアプリなので、blogress/settings.pyに追記して登録します。
ついでに、REST Framework用の権限設定も追加してください。

INSTALLED_APPS = [
    # ローカルアプリ
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig',

    # サードパーティアプリ
    'rest_framework', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

# 追記
REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.AllowAny',
    ]
}

ルーティングの設定

次にREST APIにアクセスするためのURLを指定するため、blogress/urls.pyにてルーティングの設定を行います。

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('posts.urls')),
]

これでlocalhost:8000/api/にアクセスすると、postsアプリのルーティングが参照されるようになりました。

APIバージョンをURLに書き込むらしいのですが、私はヘッダにバージョンを付与する方針で行きます。

アプリレベルのルーティングの設定

先ほどはプロジェクトレベルのルーティング設定なので、今度はアプリレベルのルーティングを行います。

新たにposts/urls.pyを作成して以下を記述してください。

from django.urls import path

from .views import PostList, PostDetail

urlpatterns = [
    path('<str:pk>/', PostDetail.as_view()),
    path('', PostList.as_view()),
]

シリアライザの設定

次に、データを送信可能な状態に整形してくれるシリアライザの設定を行います。
このシリアライザによって、REST APIでクライアントから要求されたデータがJSON形式に変換されます。

新たにposts/serializers.pyを作成して以下を記述してください。

from rest_framework import serializers
from .models import Post


class PostSerializer(serializers.ModelSerializer):

    class Meta:
        model = Post
        fields = ('id', 'author', 'title', 'slug', 'thumbnail', 'body', 'created_at',)

ビューの設定

次に、データのビューを設定します。

from rest_framework import generics

from .models import Post
from .serializers import PostSerializer


# ListCreateAPIView -> read-write endpoint
class PostList(generics.ListCreateAPIView):
    queryset = Post.objects.all()
    serializer_class = PostSerializer


# RetrieveUpdateDestoryAPIView -> ALlows read, update, delete
class PostDetail(generics.RetrieveUpdateDestroyAPIView):
    queryset = Post.objects.all()
    serializer_class = PostSerializer

一見どちらも同じ内容のクラスに見えますが、継承しているスーパークラスが違っていて、継承するクラスによってどういったビューになるかが異なるようです。

APIの確認

ここまで設定したら、実際にREST APIにアクセスしてみましょう。

$ python manage.py runserver
# http://localhost:8000/api/ にアクセス

プロジェクトレベルのルーティングでhttp://localhost:8000/api/はpostsアプリを参照するようになっているので、posts/urls.pyに設定したpath('', PostList.as_view())というアプリレベルのルーティングで記事の一覧が表示されます。

適当な記事のidをコピーしてapi/の後ろに貼り付けると、アプリレベルのルーティングで指定した通り、記事の詳細情報が開かれます。

ちなみに、IDに指定しているUUIDはハイフンを含みますが、ハイフンが無くても同じ情報が参照出来ます。

# 以下の2つは同じ情報を参照する
http://localhost:8000/api/c1e373ee-b513-4410-9c0a-b5608e2f2f06/
http://localhost:8000/api/c1e373eeb51344109c0ab5608e2f2f06/

ログインの実装

Django REST Frameworkを用いるとログインが簡単に実装出来ます。

プロジェクトレベルのルーティングblogress/urls.pyを次のように変更してください。

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('posts.urls')),
    path('api-auth/', include('rest_framework.urls')), # 追記
]

このように追記する事で、画面右上に先ほどは無かった「Log in」のリンクが表示されるようになったはずです。

一般ユーザーの追加

これまで、ユーザーは前回作成した管理者しか居ませんでしたが、権限の設定と確認を行うため一般ユーザーを追加します。

Usersの「+ Add」をクリックしてください。

適当なメールアドレスとパスワードを記入して、画面右下のSAVEをクリックしてください。

SAVEを押した後トップページから一覧に戻るとユーザーが作成されているのが分かると思います。STAFF STATUSが管理権限の有無を示しています。

権限の設定

現在は全てのAPIに対して登録に関わらず全てのユーザーが記事の投稿・削除・閲覧・更新を出来るようになっています。

ブログシステムとしては未登録ユーザーには閲覧のみ許可をしたいので、権限の設定を行いましょう。

ビューレベルの権限の設定

まずはビューレベルでの権限を設定します。
posts/views.pyを次のように変更します。

from rest_framework import generics, permissions # 追記

from .models import Post
from .serializers import PostSerializer


# ListCreateAPIView -> read-write endpoint
class PostList(generics.ListCreateAPIView):
    permission_classes = (permissions.IsAuthenticated,) # 追記
    queryset = Post.objects.all()
    serializer_class = PostSerializer


# RetrieveUpdateDestoryAPIView -> ALlows read, update, delete
class PostDetail(generics.RetrieveUpdateDestroyAPIView):
    permission_classes = (permissions.IsAdminUser,) # 追記
    queryset = Post.objects.all()
    serializer_class = PostSerializer

IsAuthenticatedは登録済みユーザーのみアクセス可能、IsAdminUserは管理者権限のあるユーザーのみアクセス可能となっています。

このように変更すると、ログインしていない状態では記事の一覧も記事の詳細も見る事が出来なくなります。

一般ユーザーでログインすると、記事の一覧は見る事が出来ます。今は詳細表示が複数並んだ形になっていて一覧表示では無いですが。

しかし、記事の詳細を見ようとすると権限で弾かれます。

同じページを管理者で見ると通常通り表示されるのが分かります。

プロジェクトレベルの権限の設定

ビューレベルでの権限の設定は、ビューが増える度に権限設定を行わなければならず、もし忘れてしまった場合に大変な事になる可能性が有ります。

Djangoではプロジェクトレベルでの権限の設定を行えるので、安全のために一旦プロジェクトレベルで管理者以外への全ての操作を禁じて、そこから各操作に対して必要な権限を設定していくのが安全かと思います。

プロジェクトレベルでの権限の設定はblogress/settings.pyで行います。

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAdminUser', # AllowAnyから変更した
    ]
}

確認のために一時的にビューレベルの権限を削除します。

from rest_framework import generics, permissions

from .models import Post
from .serializers import PostSerializer


# ListCreateAPIView -> read-write endpoint
class PostList(generics.ListCreateAPIView):
    # permission_classes = (permissions.IsAuthenticated,) # 一時的にコメントアウト
    queryset = Post.objects.all()
    serializer_class = PostSerializer


# RetrieveUpdateDestoryAPIView -> ALlows read, update, delete
class PostDetail(generics.RetrieveUpdateDestroyAPIView):
    # permission_classes = (permissions.IsAdminUser,) # 一時的にコメントアウト
    queryset = Post.objects.all()
    serializer_class = PostSerializer

プロジェクトレベルの権限の設定によって、今は管理者のみ全ての操作が可能なので、一般ユーザーでログインした場合でも見る事が出来ません。

しかし、先ほどのコメントアウトを元に戻すと一般ユーザーでも見れるようになります。

このように、プロジェクトレベルの権限の設定は、ビューレベルの権限の設定でオーバーライドが可能なので、フェイルセーフのためにプロジェクトレベルの権限を設定するのは有効です。

カスタムパーミッション

Django REST FrameworkのBasePermissionクラスのhas_object_permissionをオーバーライドする事で、独自の権限の設定を行う事が出来るようです。
has_object_permissionはユーザーのリクエストに対して何等かの判定を行った結果、許可する場合はTrueを返し、拒否する場合はFalseを返す関数です。

posts/permissions.pyに以下のように記述してください。

from rest_framework import permissions


class IsAuthorOrReadOnly(permissions.BasePermission):
    def has_object_permission(self, request, view, obj):
        # 著者がリクエストユーザーか、閲覧リクエストの場合のみ許可
        return obj.author == request.user or request.method in permissions.SAFE_METHODS

これに応じて、posts/views.pyも変更します。

from rest_framework import generics, permissions

from .models import Post
from .permissions import IsAuthorOrReadOnly # 追加
from .serializers import PostSerializer


# ListCreateAPIView -> read-write endpoint
class PostList(generics.ListCreateAPIView):
    permission_classes = (permissions.IsAuthenticated,)
    queryset = Post.objects.all()
    serializer_class = PostSerializer


# RetrieveUpdateDestoryAPIView -> ALlows read, update, delete
class PostDetail(generics.RetrieveUpdateDestroyAPIView):
    permission_classes = (IsAuthorOrReadOnly,) # IsAuthorOrReadOnlyに変更
    queryset = Post.objects.all()
    serializer_class = PostSerializer

未登録ユーザーは閲覧のみ許可されています。

登録済みの一般ユーザーも編集する事は出来ません。

著者のみ編集が可能です。

ちなみに、上記のカスタムパーミッションは「リクエストユーザーが著者、またはリクエストが閲覧の場合」を許可しているので、仮にこの一般ユーザーに管理権限を持たせても編集する事は許されません。

カスタムパーミッションを作る際は、管理者のみ絶対に操作出来るようにしておいた方が後々助かるかも知れないです。

トークン認証の実装

Django REST Frameworkにはトークンで認証する機能も予め用意されているため、blogress/settings.pyを次のように編集し、アプリを登録してから有効化します。

INSTALLED_APPS = [
    # ローカルアプリ
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig',

    # サードパーティアプリ
    'rest_framework',
    'rest_framework.authtoken', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

REST_FRAMEWORK = {
    'DEFAULT_PERMISSION_CLASSES': [
        'rest_framework.permissions.IsAdminUser',
    ],
    'DEFAULT_AUTHENTICATION_CLASSES': [ # 追記
        # HTTPヘッダにセッションIDを付与してAPIに渡す
        'rest_framework.authentication.BasicAuthentication',
        # ブラウザにログイン・ログアウトの機能を提供する
        'rest_framework.authentication.SessionAuthentication',
        # トークン認証の機能を提供する
        'rest_framework.authentication.TokenAuthentication',
    ],
}

REST Frameworkの認証に関して合計3つの設定を行ったように見えますが、上2つの項目はデフォルトで設定されている物なので、実際に有効化した機能はトークン認証1つです。

INSTALLED_APPSに変更を加えたので、マイグレーションを実行します。

# 今回はマイグレーションファイルは既に用意されているのでmigrateだけ
$ python manage.py migrate

AUTH TOKENという項目が増えていると思います。

RESTでログイン・ログアウト・パスワードリセットを提供

これを実装するために、追加のパッケージを導入する。

# Django-Rest-Authのインストール
$ pip install django-rest-auth

例の如く、blogress/settings.pyにアプリを登録します。カスタムユーザーモデルを使用しているので、それについての設定も行います。

INSTALLED_APPS = [
    # ローカルアプリ
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig',

    # サードパーティアプリ
    'rest_framework',
    'rest_framework.authtoken',
    'rest_auth', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

# 追記
REST_AUTH_SERIALIZERS = {
    'USER_DETAILS_SERIALIZER': 'users.serializers.UserSerializer'
}

そして、上記機能を行うためにblogress/urls.pyでプロジェクトレベルのルーティングを設定しましょう。

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('posts.urls')),
    path('api-auth/', include('rest_framework.urls')),
    path('api/rest-auth/', include('rest_auth.urls')), # 追加
]

これで、以下のURLでそれぞれの機能が提供されるようになったようです。

# ログイン
http://localhost:8000/api/rest-auth/login/
# ログアウト
http://localhost:8000/api/rest-auth/logout/
# パスワードリセット
http://localhost:8000/api/rest-auth/reset/
# パスワードリセットの確認
http://localhost:8000/api/rest-auth/reset/confirm/

恐らく、先ほどまでのログイン・ログアウトはAPIのサイトというかDjango自体のページでの処理で、APIを扱うような形では利用出来なかったためにこのようなパッケージを導入するようになっていると思います。

RESTでサインアップを提供

サインアップとは所謂登録処理です。これも別のパッケージが必要なようです。

# Django-AllAuthのインストール
$ pip install django-allauth

blogress/settings.pyでアプリの登録を行います。

INSTALLED_APPS = [
    # ローカルアプリ
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig',

    # サードパーティアプリ
    'rest_framework',
    'rest_framework.authtoken',
    'allauth', # 追記
    'allauth.account', # 追記
    'allauth.socialaccount', # 追記
    'rest_auth',
    'rest_auth.registration', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'django.contrib.sites', # 追記
]

# メールで認証確認をする時に使うバックエンドの指定
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
# sitesフレームワークの1つでいくつかのDjangoプロジェクトから複数のWebサイトをホストするためのID
SITE_ID = 1

EMAIL_BACKENDはともかく、SITE_IDは何なのか良く分かりませんでした。とりあえず使わなくても大丈夫だそうなのでこのまま行きます。

blogress/urls.pyを編集して、プロジェクトレベルのルーティングの設定を行います。

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('posts.urls')),
    path('api-auth/', include('rest_framework.urls')),
    path('api/rest-auth/', include('rest_auth.urls')),
    path('api/rest-auth/registration/', include('rest_auth.registration.urls')), # 追加
]

そしてマイグレーションを実行します。

$ python manage.py migrate

これで、http://localhost:8000/api/rest-auth/registration/から登録が出来るようになりました。SMTPサーバーの設定をすればメール通知も可能のようです。

ここから登録すると、トークン認証を有効化している場合に同時にトークンが発行されるようです。

ユーザーのビュー

postsアプリでposts/serializers.pyとposts/views.pyを作成してビューを作ったように、ユーザーのビューも作成します。

users/serializers.pyを次のように記述します。

from rest_framework import serializers
from .models import User


class UserSerializer(serializers.ModelSerializer):

    class Meta:
        model = User
        fields = ('id', 'username',)

そして、users/views.pyを次のように記述します。

from rest_framework import generics, permissions

from .models import User
from .serializers import UserSerializer


class UserList(generics.ListCreateAPIView):
    permission_classes = (permissions.IsAuthenticated,)
    queryset = User.objects.all()
    serializer_class = UserSerializer


class UserDetail(generics.RetrieveUpdateDestroyAPIView):
    permission_classes = (permissions.IsAuthenticated,)
    queryset = User.objects.all()
    serializer_class = UserSerializer

このビューにアクセス出来るようにルーティングを設定しましょう。

まずはプロジェクトレベルのルーティングblogress/urls.pyから設定します。

from django.contrib import admin
from django.urls import include, path

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/', include('posts.urls')),
    path('api/users/', include('users.urls')),
    path('api-auth/', include('rest_framework.urls')),
    path('api/rest-auth/', include('rest_auth.urls')),
    path('api/rest-auth/registration/', include('rest_auth.registration.urls')),
]

そして、アプリレベルのルーティングusers/urls.pyを設定します。

from django.urls import path

from .views import UserList, UserDetail


urlpatterns = [
    path('<str:pk>/', UserDetail.as_view()),
    path('', UserList.as_view()),
]

全て設定して、http://localhost:8000/api/users/にアクセスするとユーザー一覧が見られます。

管理者で見ていますが、権限は一般ユーザー以上にしています。

記事と同じくIDを末尾に付けるとそのユーザーの詳細表示が出来ます。

ViewSetsでViewを統合

現在は、UserとPostに対してそれぞれListとDetailが存在しますが、これをViewSetsを使って統合します。

posts/views.pyは統合を行うと以下のような形になります。

from rest_framework import generics, permissions, viewsets

from .models import Post
from .permissions import IsAuthorOrReadOnly # 追加
from .serializers import PostSerializer


class PostViewSet(viewsets.ModelViewSet):
    permission_classes = (IsAuthorOrReadOnly,)
    queryset = Post.objects.all()
    serializer_class = PostSerializer

同じようにusers/views.pyも統合します。

from rest_framework import generics, permissions, viewsets

from .models import User
from .serializers import UserSerializer


class UserViewSet(viewsets.ModelViewSet):
    permission_classes = (permissions.IsAuthenticated,)
    queryset = User.objects.all()
    serializer_class = UserSerializer

このままではエラーが出るので、次にルーティングを編集します。

SimpleRouterでURLを統合

ビューの次はURLの統合です。

リスト表示と詳細表示の2つがあったposts/urls.pyをSimpleRouterを用いて統合します。

from django.urls import path
from rest_framework.routers import SimpleRouter

from .views import PostViewSet

router = SimpleRouter()
router.register('', PostViewSet, basename='posts')

urlpatterns = router.urls

同じくusers/urls.pyも統合します。

from django.urls import path
from rest_framework.routers import SimpleRouter

from .views import UserViewSet

router = SimpleRouter()
router.register('', UserViewSet, basename='users')

urlpatterns = router.urls

これまで見て来たリストや詳細表示が変わらず見られる事が確認出来ると思います。

OpenAPIを使ってドキュメント表示

OpenAPIを使うとDjango REST FrameworkのAPIスキーマを自動生成出来るようです。

# OpenAPIRendererに必要なPyYAMLをインストール
$ pip install pyyaml

blogress/urls.pyを編集して、プロジェクトレベルのルーティングにスキーマへのルーティングを追記します。

from django.contrib import admin
from django.urls import include, path
from rest_framework.schemas import get_schema_view # 追記
from django.views.generic import TemplateView # 追記

urlpatterns = [
    path('admin/', admin.site.urls),
    path('api/posts/', include('posts.urls')),
    path('api/users/', include('users.urls')),
    path('api-auth/', include('rest_framework.urls')),
    path('api/rest-auth/', include('rest_auth.urls')),
    path('api/rest-auth/registration/', include('rest_auth.registration.urls')),
    path('schema/', get_schema_view( # スキーマ表示の追加
        title="Blogress",
        description="API for all things …"
    ), name='openapi-schema'),
    path('docs/', TemplateView.as_view( # ドキュメント表示の追加
        template_name='swagger-ui.html',
        extra_context={'schema_url':'openapi-schema'}
    ), name='swagger-ui'),
]

加えて、ドキュメント表示では表示用のテンプレートファイルが必要になるので、まずはテンプレートディレクトリをblogress/settings.pyで設定しましょう。

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': ['templates'], # リスト内に追記
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

そしてこれに対応するようにtemplates/ディレクトリを作成してください。

スキーマのドキュメント表示用のテンプレートはいくつか用意されているようですが、今回はswagger-ui.htmlを利用します。

なので、templates/swagger-ui.htmlを作成し、以下の内容を記述してください。

<!DOCTYPE html>
<html>
  <head>
    <title>Blogress API References</title>
    <meta charset="utf-8"/>
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="stylesheet" type="text/css" href="//unpkg.com/swagger-ui-dist@3/swagger-ui.css" />
  </head>
  <body>
    <div id="swagger-ui"></div>
    <script src="//unpkg.com/swagger-ui-dist@3/swagger-ui-bundle.js"></script>
    <script>
    const ui = SwaggerUIBundle({
        url: "{% url schema_url %}",
        dom_id: '#swagger-ui',
        presets: [
          SwaggerUIBundle.presets.apis,
          SwaggerUIBundle.SwaggerUIStandalonePreset
        ],
        layout: "BaseLayout"
      })
    </script>
  </body>
</html>

新しくディレクトリを手動作成するのはこのシリーズでは初めてなので、確認も兼ねてディレクトリツリーを図示します。

blogress/ (プロジェクトルート)
|-- blogress/
|-- posts/
|-- templates/ (テンプレートディレクトリ)
   |-- swagger-ui.html (テンプレートファイル)
|-- users/
|-- db.sqlite3
|-- manage.py

これで、http://localhost:8000/schema/やhttp://localhost:8000/docs/に繋ぐとそれぞれの表示形式でAPIスキーマを見る事が出来ます。

こちらが生のスキーマです。

そしてこちらがswagger-ui.htmlで装飾表示されたスキーマです。

まとめ

Reactと連携させるためにはもう少し作業が必要ですが、バックエンド側のRESTful APIの基礎的な実装が終わりました。

ほとんどDjangoの機能で実現出来て正直驚きました。

ただ、ほぼ自動で行ってくれるので内部の理解が難しい部分もあるため、使いこなすには時間が掛かりそうです。

参考

• Django REST Framework の使い方メモ
• Schema
• Documenting your API
• Django REST framework 3.10

しかしある程度触っていると、何処で何が行われているのかが分からないため、いざプラグインが存在しないような機能が欲しくなった時や、そもそもプラグインでは実現出来ないようなWordPressの根幹の部分が変更したくなった時に、モヤモヤする事が多くなりました。

プラグインで何とかなる場面は自分でプラグインを作れば良いのですが、そのような解決法ではプラグインを作る学習コストはともかく最終的にWordPressがプラグインでゴテゴテになってしまい、精神的・処理コスト的にあまり嬉しくはありません。

そもそも、プラグインではほとんどどうにもならないWordPressのデータ管理方法や記事の下書き等のシステム等色々な面で自分の好みとは違う点がある事に気付いたので、だったらいっその事自分の好みにあったブログシステムを自作してみようと思いました。

作りたい物

以下の機能を満たす自分用のブログシステムを作りたいと考えています。

• 記事の表示
• Markdownで記事が書ける
• 記事の執筆
• ブログテンプレートをある程度簡単に差し替え
• SEO対策としてXMLサイトマップ生成やOGPタグの設定機能
• マルチユーザー

構成

今回はウェブサイトの仕組みを学ぶ目的よりも、ブログシステムを作りたいという意思の方が強いため、一から四くらいまではフレームワークやライブラリに任せて、その先で目標のシステムを構築する事にします。

ウェブサイトについては完全に素人なので、自分が考えられる範囲で考えた以下の構成で構築を行います。

• Django + Django REST Framework + CORS
• React + Axios

簡単に説明すると、Djangoでバックエンドを実装して、Reactでフロントエンドを実装します。
その時、Django側はREST FrameworkとCORSを導入する事で、React側はAxiosを導入する事で双方の連携が取れるようにします。

Django : バックエンド

Djangoは、RailsやLaravelと並ぶPythonの有名なウェブフレームワークの一つです。

Django REST Framework

本来のDjangoはバックエンドとしてサーバー機能と、フロントエンドとして実際に表示する画面を生成する機能の両方を備えた総合的なフレームワークですが、今回はREST Frameworkを用いる事で、Djangoにはデータの管理と配信に徹してもらう事にします。

CORS

Cross-Origin Resource Sharingの略で、異なるドメイン間で動作するアプリケーションがリソースを共有するための仕組みだそうです。

今回はDjango(ポート8000番) + React(ポート3000番)で異なる2つのシステムが稼働しているため、これが必要になるようです。

React : フロントエンド

Reactは、Facebookによってオープンソースで開発されているJavaScriptのUI構築フレームワークです。

詳しい事は分かりませんが、良い感じのウェブ画面を作ってくれる物だと思っています。

今回は、Djangoから受け取ったデータを元にブログの画面を構成する役割を担ってもらいます。

Axios

ReactでREST APIへのリクエスト処理を実装するためのライブラリです。

これを使ってDjangoで用意したREST APIへアクセスし、必要なデータの取得や書き込みを行います。

Djangoでバックエンドを作る

早速作っていきます。

Djangoのインストール

まずはPythonにDjangoをインストールします。仮想環境等は好みで作成してください。

# バージョン確認
python -V
Python 3.7.4

# Djangoのインストール pip install django djangorestframework django-cors-headers

プロジェクトのセットアップ

きちんとPATHが通っていればDjangoのコマンドが利用出来るはずですので、それを使ってDjangoのプロジェクトを立ち上げます。
プロジェクト名は何でも良いですが、今回はWordPressに感化されたのでblogressと名付けます。

# プロジェクトの作成
django-admin startproject blogress
# 作成されたディレクトリに移動 cd blogress

以下のような内部構造を持つディレクトリblogressが生成されたと思います。
以降は、作成されたプロジェクトルートblogress/内で話を進めます。

blogress/ (以降何も表記しなければここがルートディレクトリ)
|-- blogress/
    |-- 省略...
    |-- settings.py
|-- manage.py

Djangoのプロジェクトは、アプリと呼ばれる複数の機能から成り立っています。

ユーザーモデルの変更

デフォルトのDjangoでは、ユーザー名とパスワードでログインするユーザーモデルが定義されていますが、まずはこれをメールアドレスとパスワードでログインする仕様に変更します。

まず、カスタムユーザーのアプリを追加します。Djangoでは、それぞれ異なる機能を持った複数のアプリからプロジェクトが成り立っているため、何か特定の機能を追加する場合にはまずアプリを追加します。

# アプリの追加
$ python manage.py startapp users

追加すると、プロジェクトルートにusers/というディレクトリが作成されたと思います。

blogress/
|-- blogress/
|-- users/ # 作成された
|-- manage.py

アプリを追加したので、まずはblogress/settings.pyにアプリを登録しましょう。
また、今から作るUserというカスタムユーザーモデルを使用するための設定も記述します。

# カスタムユーザーモデルの設定
AUTH_USER_MODEL = 'users.User' # 追記

INSTALLED_APPS = [
    # アプリを登録
    'users.apps.UsersConfig', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

アプリを登録したら、users/models.pyにモデルを定義します。

import uuid
from django.db import models
from django.core.mail import send_mail
from django.contrib.auth.models import PermissionsMixin
from django.contrib.auth.base_user import AbstractBaseUser
from django.utils.translation import ugettext_lazy as _
from django.utils import timezone
from django.contrib.auth.base_user import BaseUserManager


class UserManager(BaseUserManager):
    """ユーザーマネージャー."""

    use_in_migrations = True

    def _create_user(self, email, password, **extra_fields):
        """Create and save a user with the given username, email, and
        password."""
        if not email:
            raise ValueError('The given email must be set')
        email = self.normalize_email(email)

        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', False)
        extra_fields.setdefault('is_superuser', False)
        return self._create_user(email, password, **extra_fields)

    def create_superuser(self, email, password, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_staff') is not True:
            raise ValueError('Superuser must have is_staff=True.')
        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')

        return self._create_user(email, password, **extra_fields)


class User(AbstractBaseUser, PermissionsMixin):
    """カスタムユーザーモデル."""
    id = models.UUIDField(default=uuid.uuid4,
                            primary_key=True, editable=False)

    email = models.EmailField(_('email address'), unique=True)
    username = models.CharField(_('ニックネーム'), max_length=150, blank=True)

    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 = 'email'
    REQUIRED_FIELDS = []

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

    def get_full_name(self):
        full_name = '%s' % (self.username)
        return full_name.strip()

    def get_short_name(self):
        """Return the short name for the user."""
        return self.username

    def email_user(self, subject, message, from_email=None, **kwargs):
        """Send an email to this user."""
        send_mail(subject, message, from_email, [self.email], **kwargs)

Djangoの管理画面でもこのカスタムユーザーモデルを扱うために、users/admin.pyを以下の通り記述します。

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.forms import UserChangeForm, UserCreationForm
from django.utils.translation import ugettext_lazy as _
from .models import User


class MyUserChangeForm(UserChangeForm):
    class Meta:
        model = User
        fields = '__all__'


class MyUserCreationForm(UserCreationForm):
    class Meta:
        model = User
        fields = ('email',)


class MyUserAdmin(UserAdmin):
    fieldsets = (
        (None, {'fields': ('email', 'password')}),
        (_('Personal info'), {'fields': ('username',)}),
        (_('Permissions'), {'fields': ('is_active', 'is_staff', 'is_superuser',
                                       'groups', 'user_permissions')}),
        (_('Important dates'), {'fields': ('last_login', 'date_joined')}),
    )
    add_fieldsets = (
        (None, {
            'classes': ('wide',),
            'fields': ('email', 'password1', 'password2'),
        }),
    )
    form = MyUserChangeForm
    add_form = MyUserCreationForm
    list_display = ('email', 'username', 'is_staff')
    list_filter = ('is_staff', 'is_superuser', 'is_active', 'groups')
    search_fields = ('email', 'username')
    ordering = ('email',)

admin.site.register(User, MyUserAdmin)

これらの実装によって、Djangoのユーザー及び管理画面でのユーザーが定義したカスタムユーザーモデルに置き換えられます。

記事に関するアプリの追加

カスタムユーザーモデルを設定したら、今度は記事の投稿や表示を行うアプリpostsを追加しましょう。

# アプリの追加
$ python manage.py startapp posts

アプリを追加したので、blogress/settings.pyに登録しましょう。

INSTALLED_APPS = [
    # アプリを登録
    'users.apps.UsersConfig',
    'posts.apps.PostsConfig', # 追記

    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
]

次に記事のモデルをposts/models.pyに実装します。一般的なブログ記事が持つような情報を含む以下のようなモデルを作成しました。

import uuid
from django.db import models
from django.contrib.auth import get_user_model
User = get_user_model()


class Post(models.Model):
    # 記事ID(PRIMARY KEY)
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # 著者
    author = models.ForeignKey(User, on_delete=models.CASCADE)
    # 記事タイトル
    title = models.CharField(max_length=64)
    # スラッグ(URLに使う記事識別子)
    slug = models.SlugField(unique=True)
    # サムネイルURL
    thumbnail = models.URLField(blank=True)
    # 記事本文
    body = models.TextField(blank=True)
    # 記事の作成日時と更新日時
    created_at = models.DateTimeField(auto_now_add=True)
    updated_at = models.DateTimeField(auto_now=True)

    def __str__(self):
        return self.title

記事の管理を出来るように管理者へ記事の管理権限を登録します。
posts/admin.pyに以下を記述してください。

from django.contrib import admin
from .models import Post

admin.site.register(Post)

ここまで実装したら、マイグレーションを行います。

$ python manage.py makemigrations
$ python manage.py migrate

データベースマイグレーション

マイグレーションとは、データベースの定義を自動的に管理する機能です。

Djangoでは新たなアプリを登録した際や、アプリの持つデータ構造が変わった際にこの操作が必要になります。

マイグレーションの情報が記載されたファイルを用意して順番に適用するので、そのファイルをもとにしたロールバック(変更を元に戻す)機能も付属しているみたいですが、今の所はよく分かっていません。

実際にマイグレーションを行う場合は、以下のコマンドを実行します。

# マイグレーションの情報を生成
python manage.py makemigrations
# マイグレーションの実行(IDは入力しなくても良い) python manage.py migrate マイグレーションID

管理者の作成

Djangoの管理パネルにログインするための管理者を作成します。
デフォルトではユーザー名、メールアドレス、パスワードを聞かれますが、カスタムユーザーモデルを適用しているのでメールアドレスとパスワードのみ登録します。

$ python manage.py createsuperuser
Email address: test@mail.com
Password:
Password (again):
# パスワードが単純過ぎたりすると聞かれる
# Bypass password validation and create user anyway? [y/N]: y
Superuser created successfully.

確認のため、管理コンソールへアクセスしてみましょう。

# Djangoサーバーの起動
$ python manage.py runserver
# http://localhost:8000/admin/ へアクセス

ちなみに、Djangoではサーバーを起動した状態でアプリ等のスクリプトに変更が有ると自動的に再読み込みを行うので、開発中にいちいちサーバーを落とす必要はありません。

Postsのデータの作成

管理画面からPostsのデータを作成してみます。

管理画面にまずログインします。

Postsの[+ Add]から、タイトルや本文のデータを入力して保存しましょう。

適当に項目を埋めてSAVEを押します。太字になっている項目は必須です。今回はthumbnailのみ空欄を許可しているので、それ以外の部分を埋める必要があります。

ひとまず3つほど記事を作成しました。

テストコードの記述

せっかく記事のモデルを作ったので、Djangoのテスト機能を使ってテストを行いましょう。

適当なユーザーがタイトル等諸々の情報を入力して投稿出来るかというテストです。

from django.test import TestCase
from django.contrib.auth import get_user_model

from .models import Post
User = get_user_model()

class BlogTests(TestCase):
    @classmethod
    def setUpTestData(cls):
        # Create a User
        testuser1 = User.objects.create_user(
            email='testuser1@example.com',
            password='abc123!'
        )
        testuser1.save()

        # Create a blog post
        test_post = Post.objects.create(
            author=testuser1,
            title='Blog title',
            slug='test-post1',
            thumbnail='https://test.com/dog.jpg',
            body='Body content...'
        )
        test_post.save()

    def test_blog_content(self):
        post = Post.objects.get()
        expected_author = f'{post.author}'
        expected_title = f'{post.title}'
        expected_slug = f'{post.slug}'
        expected_thumbnail = f'{post.thumbnail}'
        expected_body = f'{post.body}'
        self.assertEquals(expected_author, 'testuser1@example.com')
        self.assertEquals(expected_title, 'Blog title')
        self.assertEquals(expected_slug, 'test-post1')
        self.assertEquals(expected_thumbnail, 'https://test.com/dog.jpg')
        self.assertEquals(expected_body, 'Body content...')

書き終えたらCtrl + Cでいったんサーバーを終了して以下のコマンドで実行します。

$ python manage.py test
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.
----------------------------------------------------------------------
Ran 1 test in 0.117s

OK
Destroying test database for alias 'default'...

どうやら上手くテストが通ったようです。

まとめ

Djangoのインストールから、ブログシステムの基本となる記事の管理の基礎を作成しました。

Djangoはフルスタックなフレームワークなので覚える事が多いですが、徐々に慣れていきたいです。

参考

• Django REST Framework の使い方メモ
• Customizing authentication in Django
• DjangoのUserモデルカスタマイズ（UUIDを使う）

何でしょうか、はい。容量です。

ウェブサイトの画像の容量の問題を解決するために、既にimgurやその他の画像クラウドストレージサービスに画像を置いている方も居ると思います。

Google フォトも他と同じく画像用クラウドストレージサービスの1つなのですが、Google フォトにはURLを変更する事で自動でサイズ変更やサムネイル作成のような事が出来て、他のサービスよりも使い勝手が良いです。

そこで、今回はGoogle フォトを使ったブログやウェブサイトの容量問題を解決する方法をご紹介します。

環境

以下の環境を想定して解説しますが、他のブラウザでも同じように出来るはずです。

• Google Chrome

Google フォト

Google フォトとは、Googleが運営する画像に特化した無料のクラウドストレージサービスです。Androidユーザーには割とお馴染みの機能で、最近のAndroidは特に設定しなければ自動でGoogle フォトに写真がバックアップされます。

Google フォト 思い出をすべて無料で保存でき、ファイルは自動的に整理されます。

利用にはGoogleアカウントが必要で、Google Driveの容量を使って画像を保存します。

高画質モードで容量無制限

他の画像用クラウドストレージサービスと1つ異なる点が有って、Google フォトではなんと「高画質モード」では保存容量が無制限なのです。

これは、画像を保存する際にGoogle側の指定した形式に画像を変換する代わりに、保存容量をカウントしないというモードです。最近、「高画質モード」の設定が更に高画質化したため、今ではほとんどオリジナルの画像と見分けのつかない画質で無制限に保存出来るようになりました。

ちなみに、「元のサイズモード」では通常通りGoogle Driveの容量を消費します。

Google フォトで容量問題を解決しよう

Google フォトを開いたら、まず左上の{≡}メニューから設定を開きます。

設定の上の方にある写真と動画のアップロード サイズから高画質を選べば、次回からアップロードされる画像が高画質モード(=容量無制限)で保存されます。

後は、右上の{写真を追加}やドラッグアンドドロップで画像をアップロードして、アップロードした画像を{左クリック}して拡大します。

拡大したら、同じく右上にある{共有}ボタンから、共有用のリンクを取得します。

共有用のリンクが取得出来たら、その画像を所有するGoogleアカウントにログインしていないブラウザからリンクを開き、先ほどと同じように画像を{左クリック}して拡大したら、{右クリック}して画像アドレスをコピーしましょう。

コピーされた画像アドレスは以下のようになります。この画像アドレスをブログに挿入すると、画像を表示する事が可能です。

また、Google フォトにはURLを変更する事で簡単に画像のリサイズを行ってくれる機能があるため、以降で説明します。

https://lh3.googleusercontent.com/k9Zdgzk_LX8vB4XmGX8f_n_a3vtDPzUpmE6eZ2TvoTVoPeXJ0H0SBM5q7yiIedi5r51uPnUEvEX44VdxeI8anbxFEOA4IQ-T_SF1uNZkR4PCYrP8dZZum8zG0lfvI3k2JXuhl9qf2g=w958-h639-no

サンプル画像: 豚の貯金箱に入らなかった万札のフリー画像（写真）

(その画像を所有するGoogleアカウントにログインしていないブラウザは、Google Chromeやその他のブラウザに搭載されているシークレットウィンドウで十分です。これを行わないと、コピーした画像アドレスが固定の物では無いため、ブログに貼っても後々見れなくなります。)

画像アドレスの編集

Google フォトでは画像アドレスの末尾のパラメータを編集する事で簡単にリサイズやサムネイル作成が行えます。

# =の末尾を編集すると様々な画像が生成出来る
https://lh3.googleusercontent.com/k...g=w958-h639-no

画像をリサイズする

画像をリサイズする方法は大きく分けて3つあります。

縦幅か横幅の大きい方を基準にリサイズ

末尾のパラメータを=sN(Nは整数)とする事で、縦幅と横幅の大きい方の幅をNピクセルとして画像を取得します。

サンプル画像は横幅の方が大きいので、=s200とすると横幅を200ピクセルとして縦幅が自動調整されます。

https://lh3.googleusercontent.com/k...g=s200

縦幅か横幅のどちらかを指定してリサイズ

末尾のパラメータを=wN(横幅, Nは整数)か=hN(縦幅, Nは整数)とすると、指定した方の長さをNピクセルとして画像を取得します。

サンプル画像は横幅の方が大きいので、=s200は大きい方の長さを指定するため、=w200と同じ結果になります。

https://lh3.googleusercontent.com/k...g=w200

https://lh3.googleusercontent.com/k...g=h200

縦幅と横幅を指定してリサイズ

末尾のパラメータを=wN-hMと指定する事で、縦横のどちらも指定された長さの上限を超えないように画像を取得します。

結果は=wNと=hMを単体で指定した時のどちらかとなりますが、縦幅と横幅はどちらも指定された長さを超えないような画像が取得されます。

# =w200とした時に縦幅hが50を超えるので、=h50の画像が取得される
https://lh3.googleusercontent.com/k...g=w200-h50

# =h50とした時に横幅wが50を超えるので、=w50の画像が取得される
https://lh3.googleusercontent.com/k...g=w50-h50

切り出し

先ほどの末尾のパラメータに-cを追加する事で、画像を正方形に切り出します。

# 300x300の画像が取得される
https://lh3.googleusercontent.com/k...g=s200-c
# 同じ結果が得られます
https://lh3.googleusercontent.com/k...g=w200-c
https://lh3.googleusercontent.com/k...g=h200-c

サイズを指定して切り出し

末尾のパラメータを=wN-hM-cと指定する事で、指定されたサイズの画像を切り出します。

# 200x50の画像が取得される
https://lh3.googleusercontent.com/k...g=w200-h50-c

サムネイル作成

末尾のパラメータを-cではなく-pとすると、画像中の注目領域が自動的に選択されて、その周辺が切り抜かれます。

# pを指定した場合
https://lh3.googleusercontent.com/k...g=s200-p

# cを指定した場合
https://lh3.googleusercontent.com/k...g=s200-c

フルサイズで表示

=s0、=w0、=h0のように、長さにゼロを指定すると保存されている最大の長さに自動的に調整されます。

不明なパラメータ

一応、-noというパラメータもあるようですが、効果が良く分かりません。画像が少し大きく表示される。

まとめ

以下が今回紹介したパラメータのまとめです。

Google フォトを使いこなして、容量制限とは無縁のウェブページ作成を。

参考文献

How to get a direct link to an image (of a specific size)