# コンテンツ管理システムの実装
## 1. はじめに
我々はヘッドレスコンテンツ管理システムの実現を目標にWebアプリケーションを作成した.

そもそもCMSとは、コンテンツ（画像や文章）を作成・更新・削除・読み取りできる機能を備えたソフトウェアである.

インターネット上に存在するWebページの半分がWordPressというコンテンツ管理システム（Content Management System：以下，CMS）によって作られていると言われている[1].
WordPressは
- すでに他の誰かが開発したプラグインを有効化するだけで基本の機能を拡張できること
- プラグインを開発する側になれば自分の理想となる機能を実装できる

という点で多くのWeb関係者に人気がある.

一方で
- フロントエンド（ブラウザで表示する画面そのものの実装）とバックエンド（コンテンツ管理機能やそれを動かすためのデータベース実装）などを分離しづらいために同時並行での開発作業がやりづらい
- 導入したプラグイン同士での機能の競合による不具合を自分で解決する必要がある
- シェア数が多く, ハッカーの標的になりやすい

などのデメリットも抱えている.

WordPressは通常, ブラウザからのリクエストごとにコンテンツ管理システム上で動いているデータベースを叩き, 用意されたマークアップにコンテンツの内容を埋め込んでブラウザに返却する. サーバー側でWebページを描画するため, これを Server Side Rendering (SSR)方式という.

一方現在のWeb開発のトレンドとして, JamStackというものがある.
これはWebサイトを構築するアーキテクチャの一種で,
- JavaScript (画面を構成するためのロジックを記述する)
- API (CMSとやり取りするための仕組み)
- Markup (テンプレート化されたマークアップ)

(それぞれの頭文字をとってJam)という技術で成り立っている.

JamStackで構成されたWebページは
- CMSの内容をCMSが用意したWEB APIを使って、HTML生成システムが事前にWebページを生成する
- 生成したWebページをContentsDeliveryNetwork(以下，CDN：素早くWebコンテンツを取得できるWebキャッシュサービス)にキャッシュする
- ブラウザからのリクエストに対応するのはCDNかつ, ブラウザに返却するコンテンツはすべて静的なので, 高速かつ安全にWebページを閲覧する仕組みを整えられる

という特徴がある.

このため, 従来のCMSの問題を解決したJamStack技術でWebページを作成するにはコンテンツ管理機能とフロントエンドの機能が分離しているCMSを用意する必要があり, この分離したCMSをヘッドレスCMSという.

そして今回はこのヘッドレスCMSを実装/用意した.

## 2. 目標
ヘッドレスCMSに要求される機能として,
- コンテンツそのものの定義(ブログに求められる項目とコメントに求められる項目, 著者情報に求められる項目はそれぞれバラバラかつ, Webサイトによって変わってくるために, あとから自分で定義できることが必要)
- 標準的なコンテンツの追加削除 (これはコンテンツ管理システムとして必須機能)
- コンテンツの作成更新等を行うアカウントの管理と認証
- ロールベースの権限認可機能
- 上記システムをWebページ上で管理するためのRESTful WebAPI
をそれぞれ実装する必要がある．

## 3. 考えたシステム

このシステムには次の用語が登場する.
- コンテンツ
これはこのシステムで管理される情報の集合を指す. 例えば,
- ブログ記事
- ブログのタグ
- 著者情報

などを指す.

- API
Application Programming Interfaceの略. このシステムでは, 管理しているコンテンツをRESTfulなWEB APIを通じて操作, 取得するために, エンドポイントを定義する必要がある.

- アカウント(ユーザー)
このシステムでの管理者/利用者を抽象的に表現したものである.

- 権限
このシステムで機能を利用するための権利を権限とし, 各機能に割り当てられている.

- ロール
アカウントの集合であると同時に権限の集合.
ロールに紐付いているアカウントは同じロールに紐付いている権限を保有しているものとしてサービスで扱われる. (RBAC, ロールベースアクセス制御)

このシステムではコンテンツのCRUDを提供する.
またコンテンツの項目を定義することが可能で, あとからコンテンツの定義を更新することができる.
このコンテンツ情報そのものの保管はNoSQLであるMongoDBで実装した.
これらのコンテンツはRESTfulなWEB APIを通してCRUDをするためにエンドポイント（名）を自分で設定する必要がある.

またシステムの利用者を識別するためにユーザーを事前に管理者アカウントを使って定義し, ユーザーアカウントを作成しておく. そのアカウントを使ってコンテンツのCRUDを行う.
ユーザーアカウントにはログイン・ログアウトの機能があり, ログイン中はCURDのHTTPリクエストにAuthorizationヘッダをもたせて, セッションキーを各リクエスト時に同時に送信する.

次の表1に示すエンドポイントをフロントエンドアプリケーション(Javascript製)からリクエストを送信することで各操作を実現する.

CRUDをするためのRESTful WEB API エンドポイント一覧
| RESTの種類 | エンドポイント名 | パスパラメーター | 役割 |
|-|-|-| - |
| GET (取得) | /api/v1/auth/me | なし | ログイン状態を返す, ログインしていればプロフィール情報がJSONで返却される |
| POST (作成) | /api/v1/auth/login | なし | メールアドレスとパスワードを受け付ける, ログインできればセッションキーとプロフィール情報がJSONで返却される |
| POST (作成) | /api/v1/auth/logout | なし | セッションキーを受け付ける. システム上からセッションキーが破棄される |
| POST (作成) | /api/v1/contents/:api_id | api_id: API固有のID | 定義されたAPIにコンテンツを投稿する |
| PATCH (更新) | /api/v1/contents/:api_id/:content_id | api_id: API固有のID | 定義されたAPIに投稿されたコンテンツのうち, コンテンツ固有のIDをもつコンテンツを更新する |
| GET (取得) | /api/v1/contents/:api_id | api_id: API固有のID | 定義されたAPIに投稿されたコンテンツを取得する. クエリパラメータで条件を設定し, 取得項目にフィルターできる. |
| DELETE (削除) | /api/v1/contents/:api_id/all | api_id: API固有のID | API固有のIDをもつAPIに所属するコンテンツをすべて削除する |
| DELETE　(削除) | /api/v1/contents/:api_id/:content_id | api_id: API固有のID,content_id: コンテンツ固有のID | 指定したAPIに所属する指定したコンテンツIDをもつコンテンツを削除する |
| GET (取得) | /api/v1/meta/:api_id | api_id: API固有のID | 定義されたAPIに投稿されたコンテンツのメタ情報(投稿日時などのコンテンツ情報を含まない情報)を取得する. クエリパラメータで条件を設定し, 取得項目にフィルターできる. |
| PATCH (更新) | /api/v1/meta/:api_id/:content_id/status | api_id: API固有のID, content_id: コンテンツ固有のID | コンテンツ固有のIDの公開状態を更新する(公開 or 非公開) |
| POST (作成) | /api/v1/define | | API定義のリクエストを受け付ける |
| PATCH (更新) | /api/v1/define/:api_id | api_id: API固有のID | 指定したAPI固有のIDを持つAPIの情報(エンドポイント名, コンテンツ定義)を更新する |
| GET (取得) | /api/v1/define/:api_id | api_id: API固有のID | 指定したAPI固有のIDを持つAPIの情報(エンドポイント名, コンテンツ定義)を取得する |
| GET (取得) | /api/v1/define/all | | 定義されたAPIの情報(エンドポイント名, コンテンツ定義)をすべて取得する |
| DELETE (削除) | /api/v1/define/:api_id | api_id: API固有のID | 指定したAPI固有のIDを持つAPIを削除する |
| POST (作成) | /api/v1/user | | ユーザー登録のリクエストを受け付ける |
| PATCH (更新) | /api/v1/user/:user_id | user_id: ユーザー固有のID | 指定されたユーザーIDに該当するユーザー情報(プロフィール, パスワード)を更新する |
| GET (取得) | /api/v1/user | | 登録されたすべてのユーザー情報を送信する |
| GET (取得) | /api/v1/user/:user_id | user_id: ユーザー固有のID | 指定されたユーザーIDに該当するユーザー情報(ハッシュ化されたパスワード以外)を取得する |
| DELETE (削除) | /api/v1/user/:user_id | user_id: ユーザー固有のID | 指定されたユーザーIDに該当するユーザーを削除する |
| POST (作成) | /api/v1/role | | ロール登録のリクエストを受け付ける |
| PATCH (更新) | /api/v1/role/:role_id | role_id: ロール固有のID | 指定されたロールIDに該当するロールを更新する |
| DELETE (削除) | /api/v1/role/:role_id | role_id: ロール固有のID | パラメーターで指定されたロール固有のID |
| GET (取得) | /api/v1/role/all | | 登録されたロールをすべて取得する |

## 4. 作成したテーブル

- ユーザーテーブル, ユーザー情報(メールアドレス,パスワード, プロフィール)を管理する

| usersテーブル | 型 | 役割 |
| - | - | - |
| (PK) user_id | VARCHAR(40) | ユーザー固有のID |
| nick_name | VARCHAR(128) | ニックネーム |
| (PK) mail | VARCHAR(256) | メールアドレス |
| password_hash |VARCHAR(512)| ハッシュ化したパスワード |
|is_lock |BOOLEAN| 更新不可能フラグ, 管理者アカウントのみ有効 |

- ログインセッションテーブル, ログインしているユーザーを識別するセッションキー

| login_sessionテーブル | 型 | 役割 |
| - | - | - |
| (PK) session_id |VARCHAR(40)| セッションキー |
| user_id |VARCHAR(40)| ログインしているユーザーの固有ID |
| expired_at |DATETIME| 有効期限, ログイン時にセッションキーの有効期限が現在時刻を超えている場合, 破棄される |

- ロールテーブル, ロールそのものを定義するテーブル

| rolesテーブル | 型 | 役割 |
| - | - | - |
| (PK) role_id | VARCHAR(40)| ロール固有のID |
| role_name | VARCHAR(512) | ロール名 |
| is_lock | BOOLEAN| 更新不可能フラグ, 管理者ロールのみ有効 |

- ユーザーロールテーブル, ユーザーとロールを関連付ける中間テーブル

| user_roleテーブル | 型 | 役割 |
| - | - | - |
|(PK) user_role_id|VARCHAR(80)| ユーザーロール識別用カラム, user_idとrole_idを結合したものを格納することで, 重複した関係レコードを登録しないようにしている |
|user_id|VARCHAR(40)| ユーザー固有のID |
|role_id |VARCHAR(40)| ロール固有のID |

- ロールアビリティーテーブル, ロールと権限を関連付けるテーブル

| role_abilityテーブル| 型 | 役割 |
| - | - | - |
|(PK) role_ability_id|VARCHAR(80)| 固有のID |
|role_id |VARCHAR(40)| 固有のID |
|ability_id|VARCHAR(512)| 固有のID |

- APIテーブル, コンテンツの集合でもあり, コンテンツ管理用APIのエンドポイントとして機能するための情報を管理する

| apisテーブル | 型 | 役割 |
| - | - | - |
|(PK) id |VARCHAR(40)| API固有のID |
|api_id |VARCHAR(40)| RESTful WEB APIのエンドポイント名 |
|is_single|BOOLEAN| 扱うコンテンツが単数か複数かを表す |

- フィールドテーブル, コンテンツが持つ属性を定義する (例えばblogAPIを用意する場合, コンテンツにはtitle:文字列, body:文字列という属性が必要になるため, api_idにはblogAPIが入って, 各レコードにtitleとbodyが登録される)

| fieldsテーブル | 型 | 役割 |
| - | - | - |
|(PK) field_id |VARCHAR(40)| フィールド固有のID |
|api_id |VARCHAR(40)| API固有のID,APIに紐付けられている |
|field_name|VARCHAR(40)| フィールド名 |
|field_type|VARCHAR(40)| フィールドのデータ型(文字列,数字,日付,参照) |
|relation_api |VARCHAR(40)| フィールドが他のAPIのコンテンツを参照する場合, そのAPIの固有IDを指定する |

- クライアントテーブル BOTやページジェネレーターがコンテンツを取得するためにクライアントとして登録する

| clientsテーブル | 型 | 役割 |
| - | - | - |
|(PK) client_id |VARCHAR(80)| クライント固有のID |
|api_id |VARCHAR(80)| API固有のID,APIに紐付けられている |
|client_name |VARCHAR(80)| クライアント名 |
|client_secret |VARCHAR(512)| クライアントシークレット, クライアントからリクエストを飛ばすときはクライアントシークレットをAuthorizationヘッダに持たせる |

- コンテンツテーブル コンテンツのメタ情報を登録する

| contentsテーブル | 型 | 役割 |
| - | - | - |
|(PK) content_id|VARCHAR(40)| コンテンツ固有のID |
| api_id |VARCHAR(40) | API固有のID, APIに紐付けられている |
| created_at | DATETIME | コンテンツ作成時刻 |
| updated_at |DATETIME | コンテンツ更新時刻 |
| published_at | DATETIME | コンテンツ公開時刻 |
| revised_at |DATETIME | コンテンツ改定時刻 |
| publish_will | DATETIME | コンテンツ公開予定時刻 |
| stop_will | DATETIME | コンテンツ公開停止時刻 |

## 5. 機能を実現するSQL文と実行結果

CRUDごとにSQL文を示す.

? の部分はWebアプリケーションが変数を埋め込むためのプリペアードステートメントである.

### ユーザーセッションテーブルのCURD
- C

INSERT INTO login_session values (?,?,?)

- U
実装上アップデートすることがないのでなし
- R
セッションキー検索時

SELECT * FROM login_session WHERE session_id = ?

- D
セッションキーを破棄する

DELETE FROM login_session where session_id = ?

ユーザー削除時

DELETE FROM login_session where user_id = ?

### コンテンツテーブルのCURD
- C

INSERT INTO contents(content_id,api_id,created_at,updated_at,published_at,revised_at,created_by,updated_by,publish_will,stop_will) VALUES(?,?,?,?,?,?,?,?,?,?)

- U

UPDATE contents SET update_by = ?, update_at = ?, published_at = ? WHERE content_id = ?

- R
すべてのコンテンツ（下書きを含む）検索時

SELECT * FROM contents WHERE content_id IN (?) order by created_at

公開されたコンテンツのみ検索時検索時

SELECT * FROM contents WHERE content_id IN (?) and published_at is not null order by published_at desc

- D
コンテンツ削除時

DELETE FROM contents WHERE content_id = ?

API削除時

DELETE FROM contents WHERE api_id = ?

### ユーザーテーブルのCURD
- C

INSERT INTO users (user_id,nick_name,mail,password_hash,is_lock) VALUES(?,?,?,?,?)

- U

UPDATE users SET password_hash = ?, nick_name = ?, mail = ? WHERE user_id = ? AND is_lock = false

- R

#### メールアドレス検索時

SELECT * FROM users WHERE mail = ?

#### 全件検索時

SELECT * FROM users

- D

DELETE FROM users WHERE user_id = ? AND is_lock = false

### APIテーブルのCURD
- C

INSERT INTO apis (id,api_id,is_single) VALUES(?,?,?)

- U

UPDATE apis SET api_id = ?, is_single = ? WHERE id = ?

- R
API検索時

SELECT * FROM apis WHERE id = ?

全件取得時

SELECT * FROM apis

- D

DELETE FROM apis WHERE id = ?

### フィールドテーブルのCURD
- C

INSERT INTO fields (field_id,api_id,field_name,field_type,relation_api) VALUES(?,?,?,?,?)

- U
なし, 更新時はすべてフィールドは削除したうえでもう一度作成されなおす
- R

SELECT * FROM fields WHERE api_id = ?

- D

DELETE FROM fields WHERE field_id = ? AND api_id = ?

APIごと削除された場合

DELETE FROM fields WHERE api_id = ?

参照フィールドのうち, 参照先のAPIが削除された場合

DELETE FROM fields WHERE relation_api = ?

### ロールテーブルのCURD
- C

INSERT INTO roles (role_id,role_name,is_lock) VALUES (?,?,?)

- U

UPDATE roles SET role_name = ? WHERE role_id = ? AND is_lock = false

- R
ロール検索時

SELECT * FROM roles WHERE role_id = ?

全件取得時

SELECT * FROM roles

- D

DELETE FROM roles WHERE role_id = ? AND is_lock = false

### ユーザーロールテーブルのCURD
- C

INSERT INTO user_role (user_role_id,user_id,role_id) VALUES (?,?,?)

- U

実装上, CRDのみ必要なためなし

- R

SELECT * FROM roles WHERE role_id IN (SELECT role_id FROM user_role WHERE user_id = ?)

- D
#### ユーザーの削除時

DELETE FROM user_role WHERE user_id = ?

#### ロールの削除時

DELETE FROM user_role WHERE role_id = ?

- その他
#### ユーザーAとユーザーBが同じロールに属しているかどうか調べる

  SELECT * FROM roles WHERE role_id IN (SELECT role_id FROM user_role WHERE user_id = ? AND role_id IN (SELECT role_id FROM user_role WHERE user_id = ?))

#### 特定のユーザーが特定の権限を持っているかを調べる

  select * from role_ability inner join user_role on role_ability.role_id = role_ability.role_id where ser_id = ? and ability_id IN (?)

## 6. 実行画面/画面遷移

本画像では, ブログ用のCMSを構築する際に必要となる設定をスクリーンショットしたものである

ブログ用のCMSには次のAPIとフィールドを定義した

API名:API内容
author:筆者を管理する
|フィールド名|フィールドの用途|データ型|
|-|-|-|
|name|筆者の名前|文字列|
|introduction|筆者の自己紹介|文字列|
|icon|ブログに表示される|文字列|

blog:ブログに必要な情報を管理する
|フィールド名|フィールドの用途|データ型|
|-|-|-|
|title|記事のタイトル|文字列|
|body|記事本文|文字列|
|author|著者紹介|参照型(authorAPIを参照する)|
|related_blog|関連記事|参照型(blogAPIを参照する)|

1. ログイン画面

2. ホーム画面

3. API作成画面

4. コンテンツ新規投稿画面

5. 同様にコンテンツをもう一つ追加した場合

6. APIを更に追加 (ブログ本文用のAPIを作成)

7. 自分自身を参照するフィールドを追加, APIを更新する (関連記事を参照させるためのフィールドを定義する)
(related_blogのフィールドが追加された)

8. blogAPIに記事を投稿する
(参照型のフィールドを持つAPIの場合, 次のように参照先のAPIの画面が表示されて, 参照先APIのコンテンツを登録できるようになる)
作成すると次の表示になる

9. コンテンツの編集
次のようにコンテンツ編集画面が表示され, コンテンツの編集と公開状態の設定, 削除などができる
公開状態を変更すると次の表示になる

10. ユーザーの新規登録
11. ユーザー一覧の表示
12. ユーザーのプロフィール表示
13. ロールの新規登録
14. ロールの権限表示
15. ロールの権限更新
今回はコンテンツの投稿権限を与えるようにロールを更新する.
ロールの権限一覧画面から
ロール編集画面を開き
更新する権限を選択する
適用を押して
ロールの権限が更新されたことがわかる

16. コンテンツの取得 (WEB API)
今回はRESTfulAPI を使ってサイトジェネレーターに本CMSのAPIを利用するために, 便宜上ブラウザのRESTfulAPIを叩くためのツールを使って実行する.
このように違うセッションキーが入るとエラーが帰ってくる
正しいセッションキーを入れて, APIを実行すると, 下の図のようにCMSに投稿したコンテンツが表示される
あとはこの構造化されたデーターをサイトジェネレーターが読み込んで, WEBページを作成する

8. わかったこと、感想

9. 参考文献
[1] WordPress powers 25% of all websites - The market share among the 300+ content management system which we monitor is now at 58.7% より https://w3techs.com/blog/entry/wordpress-powers-25-percent-of-all-websites

[2] 業務システムにおけるロールベースアクセス制御 - RBACの基礎 https://qiita.com/kawasima/items/8dd7eda743f2fdcad78e
[3] 権限制御の仕組み[ロールベースアクセスコントロール(RBAC)] - ロールベースアクセスコントロールrbachttps://www.bnote.net/dataroom/rbac.html
[4] ロールベースアクセス制御（RBAC）とは？ メリットとABACとの比較 - ロールベースアクセス制御（RBAC）とは具体的に何か？ https://www.okta.com/jp/identity-101/what-is-role-based-access-control-rbac/