php crud api
v2.14.29
REST API を MySQL/MariaDB、PostgreSQL、SQL Server、または SQLite データベースに追加する単一ファイルの PHP スクリプト。
方法: 「 api.php 」を Web サーバーにアップロードし、データベースに接続するように構成すると、すぐにフル機能の REST API を使用できます。
注意: これは、PHP での TreeQL リファレンス実装です。
次のデータベース システムのいずれかに対して PDO ドライバーが有効になっている PHP 7.2 以降:
MySQL の空間機能には MySQL 5.7 / MariaDB 10.0 以降
PostgreSQL 9.5 以降と空間機能の PostGIS 2.2 以降
SQL Server 2017 以降 (2019 では Linux もサポートされます)
SQLite 3.16 以降 (空間機能はサポートされていません)
最新リリースから「 api.php 」ファイルをダウンロードします。
https://github.com/mevdschee/php-crud-api/releases/latest または以下から直接:
https://raw.githubusercontent.com/mevdschee/php-crud-api/main/api.php
これは単一ファイルのアプリケーションです。 「 api.php 」をどこかにアップロードしてお楽しみください。
ローカル開発の場合は、PHP の組み込み Web サーバーを実行できます。
php -S localhost:8080
次の URL を開いてスクリプトをテストします。
http://localhost:8080/api.php/records/posts/1
ファイルの下部にある構成を変更することを忘れないでください。
あるいは、このプロジェクトを選択した Web フレームワークに統合することもできます。以下を参照してください。
Laravel の自動 REST API
Symfony 4 用の自動 REST API
SlimPHP 4 用の自動 REST API
これらの統合では、Composer を使用してこのプロジェクトを依存関係としてロードします。
Composer を使用しない人のために、ファイル「 api.include.php 」が提供されています。このファイルには、「 src/index.php 」の構成を除く「 api.php 」のすべてが含まれており、PHP の「include」関数で使用できます。
ファイル「 api.php 」の下部にある次の行を編集します。
$config = new Config([ 'username' => 'xxx', 'password' => 'xxx', 'database' => 'xxx', ]);
これらはすべての構成オプションと、括弧内のデフォルト値です。
「ドライバー」: mysql 、 pgsql 、 sqlsrvまたはsqlite ( mysql )
"address": データベースサーバーのホスト名 (またはファイル名) ( localhost )
"port": データベースサーバーの TCP ポート (デフォルトはドライバーのデフォルト)
"username": データベースに接続するユーザーのユーザー名 (デフォルトなし)
"password": データベースに接続するユーザーのパスワード (デフォルトなし)
"database": 接続先のデータベース (デフォルトなし)
"command": データベース接続を初期化するための追加 SQL (なし)
"tables": 公開するテーブルのカンマ区切りリスト (デフォルトは「all」)
"mapping": テーブル/列マッピングのカンマ区切りリスト (マッピングなし)
"geometrySrid": WKT からジオメトリに変換するときに想定される SRID ( 4326 )
"middlewares": ロードするミドルウェアのリスト ( cors )
"controllers": ロードするコントローラーのリスト ( records,geojson,openapi,status )
"customControllers": ロードするユーザー カスタム コントローラーのリスト (デフォルトなし)
"openApiBase": OpenAPI 情報 ( {"info":{"title":"PHP-CRUD-API","version":"1.0.0"}} )
"cacheType": TempFile 、 Redis 、 Memcache 、 MemcachedまたはNoCache ( TempFile )
"cachePath": キャッシュのパス/アドレス (デフォルトはシステムの一時ディレクトリ)
"cacheTime": キャッシュが有効な秒数 ( 10 )
"jsonOptions": JSON のエンコードに使用されるオプション ( JSON_UNESCAPED_UNICODE )
"debug": "X-Exception" ヘッダーのエラーを表示します ( false )
"basePath": API の URI ベース パス (デフォルトでは PATH_INFO を使用して決定されます)
すべての構成オプションは環境変数としても使用できます。構成オプションは、大文字、「PHP_CRUD_API_」プレフィックス、および単語区切りのアンダースコアを使用して記述します。たとえば、次のようになります。
PHP_CRUD_API_DRIVER=mysql
PHP_CRUD_API_ADDRESS=ローカルホスト
PHP_CRUD_API_PORT=3306
PHP_CRUD_API_DATABASE=php-crud-api
PHP_CRUD_API_USERNAME=php-crud-api
PHP_CRUD_API_PASSWORD=php-crud-api
PHP_CRUD_API_DEBUG=1
環境変数は、PHP 設定よりも優先されます。
次の制限と制約が適用されます。
主キーは自動インクリメント (1 から 2^53) または UUID である必要があります。
複合主キーと複合外部キーはサポートされていません
複雑な書き込み（トランザクション）はサポートされていません
関数 (「concat」や「sum」など) を呼び出す複雑なクエリはサポートされていません
データベースは外部キー制約をサポートし、定義する必要があります
SQLite では、bigint 型の自動インクリメント主キーを持つことはできません
SQLite はテーブルの列 (構造) の変更をサポートしていません
次の機能がサポートされています。
Composer のインストールまたは 1 つの PHP ファイルで、簡単に導入できます。
コードが非常に少なく、適応と保守が簡単
POST 変数を入力としてサポート (x-www-form-urlencoded)
JSON オブジェクトを入力としてサポートします
JSON 配列を入力としてサポート (バッチ挿入)
型ルールとコールバックを使用して入力をサニタイズおよび検証する
データベース、テーブル、列、レコードの権限システム
マルチテナントのシングルおよびマルチデータベースレイアウトがサポートされています
クロスドメインリクエストに対するマルチドメイン CORS サポート
複数のテーブルからの結合結果の読み取りのサポート
複数の条件での検索サポート
ページネーション、並べ替え、上位 N リストと列の選択
ネストされた結果による関係検出 (belongsTo、hasMany、および HABTM)
PATCH によるアトミック インクリメントのサポート (カウンター用)
Base64エンコーディングでサポートされるバイナリフィールド
WKT および GeoJSON でサポートされる空間/GIS フィールドとフィルター
レガシー システムをサポートするためのテーブル名と列名のマッピング
OpenAPI ツールを使用して API ドキュメントを生成する
API キー、JWT トークン、またはユーザー名/パスワードによる認証
データベース接続パラメータは認証に依存する場合があります
JSON でのデータベース構造の読み取りのサポート
REST エンドポイントを使用したデータベース構造の変更のサポート
セキュリティ強化ミドルウェアを搭載
準拠規格: PSR-4、PSR-7、PSR-12、PSR-15、PSR-17
関連プロジェクト:
PHP-CRUD-API クイック スタート: PHP-CRUD-API を備えた、カスタマイズ可能ですぐに使用できる Docker 構成ファイル。
PHP-CRUD-API フィルター ジェネレーター: 式から PHP-CRUD-API フィルターを作成する JavaScript ライブラリ。
JS-CRUD-API: PHP-CRUD-API の API 用の JavaScript クライアント ライブラリ
PHP-API-AUTH: PHP-CRUD-API の認証プロバイダーである単一ファイルの PHP スクリプト
PHP-CRUD-UI: PHP-CRUD-API プロジェクトに UI を追加する単一ファイルの PHP スクリプト。
PHP-CRUD-ADMIN: データベース管理インターフェイスを PHP-CRUD-API プロジェクトに追加する単一ファイルの PHP スクリプト。
PHP-SP-API: SQL データベースに REST API を追加する単一ファイルの PHP スクリプト。
dexie-mysql-sync: ローカル IndexedDB と MySQL データベース間の同期。
ra-data-treeql: React Admin のデータ プロバイダーを提供する NPM パッケージ。
scriptPilot/vueuse: VueUse.org (PHP-CRUD-API をサポートする) に加えて Vue Composables。
scriptPilot/add-php-backend: MySQL、phpMyAdmin、および PHP-CRUD-API を開発環境に追加します。
VUE-CRUD-UI: PHP-CRUD-API プロジェクトに UI を追加する単一ファイルの Vue.js スクリプト。
このスクリプトのポートは次の場所にもあります。
Go-CRUD-API (作業中)
Ivan Kolchagov による Java JDBC (v1)
Java Spring Boot + jOOQ (v2: 作業中)
このスクリプトには、PHP、Java、Go、C# .net core、Node.js、Python の基本的な REST CRUD 機能のみをサポートする概念実証ポートもあります。
次のコマンドを使用して、このプロジェクトのすべての依存関係をインストールできます。
php install.php
以下を使用して、すべてのファイルを単一の「 api.php 」ファイルにコンパイルできます。
php build.php
このプロジェクトを別のプロジェクトまたはフレームワークに統合する場合は、コンパイルを使用しないことに注意してください (代わりに Composer を使用します)。
コンパイルされていないコードには次の URL からアクセスできます。
http://localhost:8080/src/records/posts/1
コンパイルされていないコードは、「 src 」ディレクトリと「 vendor 」ディレクトリにあります。 「 vendor 」ディレクトリには依存関係が含まれています。
次のコマンドを使用して、このプロジェクトのすべての依存関係を更新できます。
php update.php
このスクリプトは Composer をインストールして実行し、依存関係を更新します。
注意: 更新スクリプトは、PHP 7.0 との互換性のために、ベンダー ディレクトリ内の依存関係にパッチを適用します。
TreeQL を使用すると、SQL データベース構造 (リレーション) とクエリに基づいて JSON オブジェクトの「ツリー」を作成できます。
これは REST 標準に大まかに基づいており、json:api からも影響を受けています。
例の posts テーブルには、いくつかのフィールドしかありません。
posts ======= id title content created
以下の CRUD + List 操作は、このテーブルに作用します。
レコードを作成する場合は、リクエストを URL 形式で次のように記述できます。
POST /records/posts
以下を含む本文を送信する必要があります。
{
"title": "Black is the new red",
"content": "This is the second post.",
"created": "2018-03-06T21:34:01Z"
}そして、新しく作成されたレコードの主キーの値を返します。
2
このテーブルからレコードを読み取るには、リクエストを URL 形式で次のように記述できます。
GET /records/posts/1
ここで、「1」は、読み取るレコードの主キーの値です。次の内容が返されます:
{
"id": 1
"title": "Hello world!",
"content": "Welcome to the first post.",
"created": "2018-03-05T20:12:56Z"
}読み取り操作では結合を適用できます。
このテーブルのレコードを更新するには、リクエストを URL 形式で次のように記述できます。
PUT /records/posts/1
ここで、「1」は更新するレコードの主キーの値です。本文として送信します。
{
"title": "Adjusted title!"
}これにより、投稿のタイトルが調整されます。戻り値は設定された行数です。
1
このテーブルからレコードを削除する場合、リクエストは次のように URL 形式で記述できます。
DELETE /records/posts/1
そして、削除された行の数を返します。
1
このテーブルのレコードをリストするには、リクエストを URL 形式で次のように記述できます。
GET /records/posts
次の内容が返されます:
{
"records":[
{
"id": 1,
"title": "Hello world!",
"content": "Welcome to the first post.",
"created": "2018-03-05T20:12:56Z"
}
]
}リスト操作では、フィルターと結合を適用できます。
フィルターは、「filter」パラメーターを使用して、リスト呼び出しで検索機能を提供します。列名、カンマ、一致タイプ、別のカンマ、およびフィルタリングする値を指定する必要があります。サポートされている一致タイプは次のとおりです。
"cs": 文字列を含む (文字列には値が含まれます)
"sw": で始まる (文字列は値で始まります)
"ew": で終わる (値で終わる文字列)
"eq": 等しい (文字列または数値が完全に一致)
"lt": より小さい (数値が値より小さい)
"le": 以下 (数値が値以下)
"ge": 以上 (数値が値以上)
"gt": より大きい (数値が値より大きい)
"bt": between (数値は 2 つのカンマ区切り値の間)
"in": in (数値または文字列はカンマで区切られた値のリスト内にあります)
"is": null (フィールドには "NULL" 値が含まれます)
「n」文字を先頭に追加すると、すべてのフィルターを無効にすることができ、「eq」が「neq」になります。フィルターの使用例は次のとおりです。
GET /records/categories?filter=name,eq,Internet GET /records/categories?filter=name,sw,Inter GET /records/categories?filter=id,le,1 GET /records/categories?filter=id,ngt,1 GET /records/categories?filter=id,bt,0,1 GET /records/categories?filter=id,in,0,1
出力：
{
"records":[
{
"id": 1
"name": "Internet"
}
]
}次のセクションでは、単一のリスト呼び出しに複数のフィルターを適用する方法を詳しく説明します。
フィルタは、URL で「filter」パラメータを繰り返すことで適用できます。たとえば、次の URL です。
GET /records/categories?filter=id,gt,1&filter=id,lt,3
「id > 1かつid < 3」のすべてのカテゴリをリクエストします。 「どこで id = 2 または id = 4」が必要な場合は、次のように書く必要があります。
GET /records/categories?filter1=id,eq,2&filter2=id,eq,4
ご覧のとおり、「AND」ではなく「OR」を適用する必要があることを示すために、「filter」パラメーターに数値を追加しました。 「filter1」を繰り返し、「OR」内に「AND」を作成することもできることに注意してください。文字 (af) を追加すると 1 レベル深く進むこともできるため、ほぼすべての適度に複雑な条件ツリーを作成できます。
注意: フィルタリングできるのは、要求されたテーブル (含まれているテーブルではない) のみであり、フィルタはリスト呼び出しにのみ適用されます。
デフォルトでは、すべての列が選択されています。 「include」パラメータを使用すると、特定の列を選択できます。ドットを使用してテーブル名と列名を区切ることができます。複数の列はカンマで区切る必要があります。アスタリスク (「*」) は、「すべての列」を示すワイルドカードとして使用できます。 「include」と同様に、「exclude」パラメータを使用して特定の列を削除できます。
GET /records/categories/1?include=name GET /records/categories/1?include=categories.name GET /records/categories/1?exclude=categories.id
出力：
{
"name": "Internet"
}注意: 関連エンティティを含めるために使用される列は自動的に追加され、出力から除外することはできません。
「order」パラメータを使用すると、並べ替えることができます。デフォルトではソートは昇順ですが、「desc」を指定するとこれを逆にすることができます。
GET /records/categories?order=name,desc GET /records/categories?order=id,desc&order=name
出力：
{
"records":[
{
"id": 3
"name": "Web development"
},
{
"id": 1
"name": "Internet"
}
]
}注意: 複数の「順序」パラメータを使用して、複数のフィールドで並べ替えることができます。 「結合された」列では順序付けできません。
「size」パラメータは、返されるレコードの数を制限します。これは、「order」パラメータとともに上位 N リストに使用できます (降順を使用)。
GET /records/categories?order=id,desc&size=1
出力：
{
"records":[
{
"id": 3
"name": "Web development"
}
]
}注意: レコードの総数も知りたい場合は、「page」パラメータを使用するとよいでしょう。
「page」パラメータは、要求されたページを保持します。デフォルトのページ サイズは 20 ですが、調整できます (たとえば、50 まで)。
GET /records/categories?order=id&page=1 GET /records/categories?order=id&page=1,50
出力：
{
"records":[
{
"id": 1
"name": "Internet"
},
{
"id": 3
"name": "Web development"
}
],
"results": 2
}要素「results」は、テーブル内のレコードの総数を保持します。これは、ページネーションが使用されない場合に返されます。
注意: 順序付けられていないページはページ分割できないため、ページは主キーによって順序付けされます。
(ユーザーが作成した) コメントを含む投稿テーブルがあり、投稿にはタグを含めることができるとします。
posts comments users post_tags tags ======= ======== ======= ========= ======= id id id id id title post_id username post_id name content user_id phone tag_id created message
投稿をコメント ユーザーとタグとともにリストしたい場合は、2 つの「ツリー」パスを要求できます。
posts -> comments -> users posts -> post_tags -> tags
これらのパスは同じルートを持ち、このリクエストは次の URL 形式で記述できます。
GET /records/posts?join=comments,users&join=tags
ここでは、投稿をタグにバインドする中間テーブルを省略できます。この例では、3 つのテーブル リレーション タイプ (hasMany、belongsTo、hasAndBelongsToMany) がすべて有効であることがわかります。
「投稿」にはたくさんの「コメント」が付いています
「コメント」は「ユーザー」に属します
「post」には多くの「タグ」があり、それに属しています
これにより、次の JSON データが生成される可能性があります。
{
"records":[
{
"id": 1,
"title": "Hello world!",
"content": "Welcome to the first post.",
"created": "2018-03-05T20:12:56Z",
"comments": [
{
id: 1,
post_id: 1,
user_id: {
id: 1,
username: "mevdschee",
phone: null,
},
message: "Hi!"
},
{
id: 2,
post_id: 1,
user_id: {
id: 1,
username: "mevdschee",
phone: null,
},
message: "Hi again!"
}
],
"tags": []
},
{
"id": 2,
"title": "Black is the new red",
"content": "This is the second post.",
"created": "2018-03-06T21:34:01Z",
"comments": [],
"tags": [
{
id: 1,
message: "Funny"
},
{
id: 2,
message: "Informational"
}
]
}
]
}「belongsTo」関係が検出され、外部キーの値が参照されたオブジェクトに置き換えられていることがわかります。 「hasMany」および「hasAndBelongsToMany」の場合、テーブル名はオブジェクトの新しいプロパティとして使用されます。
作成、読み取り、更新、または削除を行う場合、URL に複数の主キー値を指定できます。また、作成および更新のリクエスト本文でオブジェクトの代わりに配列を送信する必要があります。
このテーブルからレコードを読み取るには、リクエストを URL 形式で次のように記述できます。
GET /records/posts/1,2
結果は次のようになります。
[
{
"id": 1,
"title": "Hello world!",
"content": "Welcome to the first post.",
"created": "2018-03-05T20:12:56Z"
},
{
"id": 2,
"title": "Black is the new red",
"content": "This is the second post.",
"created": "2018-03-06T21:34:01Z"
}
]同様に、バッチ更新を実行する場合、URL 形式のリクエストは次のように記述されます。
PUT /records/posts/1,2
ここで、「1」と「2」は、更新するレコードの主キーの値です。本文には、URL の主キーと同じ数のオブジェクトが含まれている必要があります。
[
{
"title": "Adjusted title for ID 1"
},
{
"title": "Adjusted title for ID 2"
}
]これにより、投稿のタイトルが調整されます。戻り値は設定された行数です。
[1,1]
これは、2 つの更新操作があり、それぞれが 1 行を設定していたことを意味します。バッチ操作ではデータベース トランザクションが使用されるため、すべて成功するかすべて失敗します (成功したものはロールバックされます)。失敗した場合、本文にはエラー文書のリストが含まれます。次の応答では、バッチの最初の操作は成功しましたが、整合性違反によりバッチの 2 番目の操作は失敗しました。
[
{
"code": 0,
"message": "Success"
},
{
"code": 1010,
"message": "Data integrity violation"
}
]バッチ操作の 1 つが失敗した場合、応答ステータス コードは常に 424 (依存関係の失敗) になります。
このテーブルに複数のレコードを挿入するには、リクエストを URL 形式で次のように記述できます。
POST /records/posts
本文には、挿入されるレコードの配列が含まれている必要があります。
[
{
"title": "Hello world!",
"content": "Welcome to the first post.",
"created": "2018-03-05T20:12:56Z"
},
{
"title": "Black is the new red",
"content": "This is the second post.",
"created": "2018-03-06T21:34:01Z"
}
]戻り値も、新しく挿入されたレコードの主キーを含む配列です。
[1,2]
DELETE のバッチ操作は PUT と同じパターンに従いますが、本文はありません。
空間サポートのために、ジオメトリ列に適用でき、「s」で始まるフィルターの追加セットがあります。
"sco": 空間が含まれています (ジオメトリに別のものが含まれています)
"scr": 空間交差 (ジオメトリが別のものと交差)
"sdi": 空間的素性 (ジオメトリが他のものから素である)
"seq": 空間的に等しい (ジオメトリが他のものと等しい)
"sin": 空間的交差 (ジオメトリが別のジオメトリと交差)
"sov": 空間的な重なり (ジオメトリが別のジオメトリと重なり合う)
"sto": 空間タッチ (ジオメトリが別のタッチ)
"swi": 内部の空間 (ジオメトリは別の内部にあります)
"原文通り": 空間は閉じています (ジオメトリは閉じていて単純です)
"sis": 空間は単純です (幾何学は単純です)
"siv": 空間は有効です (ジオメトリは有効です)
これらのフィルターは OGC 標準に基づいており、ジオメトリ列が表現される WKT 仕様も同様です。 WKT からジオメトリに変換するときに想定される SRID は構成変数geometrySridによって指定され、デフォルトは 4326 (WGS 84) であることに注意してください。
GeoJSON サポートは、GeoJSON 形式のテーブルとレコードに対する読み取り専用のビューです。次のリクエストがサポートされています。
method path - operation - description
----------------------------------------------------------------------------------------
GET /geojson/{table} - list - lists records as a GeoJSON FeatureCollection
GET /geojson/{table}/{id} - read - reads a record by primary key as a GeoJSON Feature 「 /geojson 」エンドポイントは、「 /records 」エンドポイントを内部で使用し、結合やフィルターなどのすべての機能を継承します。また、テーブルに複数のジオメトリ列がある場合に備えて、ジオメトリ列の名前を示す「geometry」パラメータもサポートしています。マップ ビューの場合、左上と右下の座標を (カンマ区切りで) 指定できる「bbox」パラメータがサポートされています。 GeoJSON 実装では、次のジオメトリ タイプがサポートされています。
ポイント
マルチポイント
ラインストリング
複数行文字列
ポリゴン
マルチポリゴン
GeoJSON 機能はデフォルトで有効になっていますが、「コントローラー」構成を使用して無効にすることができます。
従来のシステム (Wordpress など) 用の API の作成をサポートするには、ソフトウェアを変更しないとテーブル名と列名を改善できないため、テーブル名と列名をマッピングする必要があるかもしれませんが、名前の一貫性を保つために多少の改善が必要な場合があります。この構成では、次のように、等号で区切られたマッピングのカンマ区切りリストを使用してテーブルと列の名前を変更できます。
'mapping' => 'wp_posts=posts,wp_posts.ID=posts.id',
この特定の例では、(「 wp_posts 」の代わりに) 「 posts 」エンドポイントで「 wp_posts 」テーブルを公開し、そのテーブル内の列「 ID 」を「 id 」プロパティとして(大文字ではなく小文字で)公開します。
注意: これら 2 つのマッピングは重複しているため、最初の (具体性が低い) マッピングは省略される場合があります。
「middlewares」構成パラメータを使用して、次のミドルウェアを有効にできます。
「ファイアウォール」: 特定の IP アドレスへのアクセスを制限します
「sslRedirect」: HTTP ではなく HTTPS 経由で接続を強制します
「cors」: CORS リクエストのサポート (デフォルトで有効)
「xsrf」: 「Double Submit Cookie」メソッドを使用して XSRF 攻撃をブロックします。
「ajaxOnly」: XSRF 攻撃を防ぐために非 AJAX リクエストを制限します
「apiKeyAuth」：「APIキー認証」のサポート
「apiKeyDbAuth」: 「API キー データベース認証」のサポート
「dbAuth」: 「データベース認証」のサポート
「wpAuth」：「Wordpress認証」のサポート
「jwtAuth」: 「JWT認証」のサポート
「basicAuth」：「Basic認証」のサポート
"reconnect": 異なるパラメータを使用してデータベースに再接続します。
"authorization": 特定のテーブルまたは列へのアクセスを制限します。
"validation": カスタム ルールとデフォルトのタイプ ルールの入力検証エラーを返します。
"ipAddress": 作成時に保護されたフィールドに IP アドレスを入力します。
"sanitation": 作成および更新時に入力のサニテーションを適用します
「multiTenancy」: マルチテナントのシナリオでテナントのアクセスを制限します。
「pageLimits」: データベースのスクレイピングを防ぐためにリスト操作を制限します。
"joinLimits": データベースのスクレイピングを防ぐために結合パラメーターを制限します。
"textSearch": 単純なパラメーターを使用してすべてのテキスト フィールドを検索します。
「カスタマイズ」: リクエストとレスポンスのカスタマイズ用のハンドラーを提供します。
"json": JSON オブジェクト/配列としての JSON 文字列の読み取り/書き込みをサポートします。
「xml」: すべての入力と出力を JSON から XML に変換します。
「middlewares」設定パラメータは、有効なミドルウェアのカンマ区切りリストです。ミドルウェア固有の構成パラメーターを使用して、ミドルウェアの動作を調整できます。
「firewall.reverseProxy」：リバースプロキシを使用する場合は「true」に設定します（「」）
"firewall.allowedIpAddresses": 接続を許可する IP アドレスのリスト ("")
"cors.allowedOrigins": CORS ヘッダーで許可されるオリジン ("*")
「cors.allowHeaders」: CORS リクエストで許可されるヘッダー (「Content-Type、X-XSRF-TOKEN、X-Authorization」)
「cors.allowMethods」: CORS リクエストで許可されるメソッド (「OPTIONS、GET、PUT、POST、DELETE、PATCH」)
"cors.allowCredentials": CORS リクエストで資格情報を許可する場合 ("true")
"cors.exposeHeaders": ブラウザーがアクセスを許可されるホワイトリスト ヘッダー ("")
"cors.maxAge": CORS 許可の有効期間 (秒単位) ("1728000")
「xsrf.excludeMethods」: XSRF 保護を必要としないメソッド (「OPTIONS,GET」)
"xsrf.cookieName": XSRF保護Cookieの名前("XSRF-TOKEN")
"xsrf.headerName": XSRF保護ヘッダーの名前("X-XSRF-TOKEN")
"ajaxOnly.excludeMethods": AJAX を必要としないメソッド ("OPTIONS,GET")
"ajaxOnly.headerName": 必要なヘッダーの名前 ("X-Requested-With")
"ajaxOnly.headerValue": 必要なヘッダー ("XMLHttpRequest") の値
「apiKeyAuth.mode」：匿名アクセスを許可する場合は「optional」に設定します（「required」）
「apiKeyAuth.header」: API キーヘッダーの名前 (「X-API-Key」)
"apiKeyAuth.keys": 有効な API キーのリスト ("")
「apiKeyDbAuth.mode」: 匿名アクセスを許可する場合は「オプション」に設定します (「必須」)
「apiKeyDbAuth.header」: API キーヘッダーの名前 (「X-API-Key」)
"apiKeyDbAuth.usersTable": ユーザーを格納するために使用されるテーブル ("users")
"apiKeyDbAuth.apiKeyColumn": API キー ("api_key") を保持するユーザー テーブルの列
「dbAuth.mode」: 匿名アクセスを許可する場合は「optional」に設定します (「required」)
"dbAuth.usersTable": ユーザーを保存するために使用されるテーブル ("users")
「dbAuth.loginTable」: ログイン用のユーザー情報 (「ユーザー」) を取得するために使用されるテーブルまたはビュー
"dbAuth.usernameColumn": ユーザー名 ("username") を保持するユーザー テーブルの列
"dbAuth.passwordColumn": パスワード ("password") を保持するユーザー テーブルの列
"dbAuth.returnedColumns": ログインが成功したときに返される列。空は「すべて」を意味します ("")
"dbAuth.usernameFormField": ユーザー名を保持するフォーム フィールドの名前 ("username")
"dbAuth.passwordFormField": パスワードを保持するフォームフィールドの名前 ("password")
"dbAuth.newPasswordFormField": 新しいパスワード ("newPassword") を保持するフォーム フィールドの名前
"dbAuth.registerUser": /register エンドポイントを有効にする場合の JSON ユーザー データ (または "1") ("")
"dbAuth.loginAfterRegistration": 登録ユーザーが登録後にログインする必要がある場合は 1 または 0 ("")
「dbAuth.passwordLength」: パスワードに必要な最小の長さ (「12」)
"dbAuth.sessionName": 開始された PHP セッションの名前 ("")
「wpAuth.mode」：匿名アクセスを許可したい場合は「optional」に設定します（「required」）
「wpAuth.wpDirectory」: Wordpress のインストール先のフォルダー/パス (「.」)
"wpAuth.usernameFormField": ユーザー名を保持するフォームフィールドの名前 ("username")
"wpAuth.passwordFormField": パスワードを保持するフォームフィールドの名前 ("password")
「jwtAuth.mode」：匿名アクセスを許可する場合は「optional」に設定します（「required」）
"jwtAuth.header": JWT トークン ("X-Authorization") を含むヘッダーの名前
"jwtAuth.leeway": クロック スキューの許容秒数 ("5")
「jwtAuth.ttl」: トークンが有効な秒数 (「30」)
"jwtAuth.secrets": ("") を使用して JWT トークンに署名するために使用される共有シークレット
"jwtAuth.algorithms": 許可されるアルゴリズム、空は「すべて」を意味します ("")
"jwtAuth.audiences": 許可される対象ユーザー、空は「すべて」を意味します ("")
"jwtAuth.issuers": 許可される発行者、空は「すべて」を意味します ("")
"jwtAuth.sessionName": 開始された PHP セッションの名前 ("")
「basicAuth.mode」：匿名アクセスを許可する場合は「optional」に設定します（「required」）
「basicAuth.realm」: ログインを表示するときにプロンプトを表示するテキスト (「ユーザー名とパスワードが必要です」)
「basicAuth.passwordFile」: ユーザー名とパスワードの組み合わせを読み取るファイル (「.htpasswd」)
"basicAuth.sessionName": 開始される PHP セッションの名前 ("")
"reconnect.driverHandler": データベースドライバーの取得を実装するハンドラー("")
"reconnect.addressHandler": データベースアドレスの取得を実装するハンドラー("")
"reconnect.portHandler": データベースポートの取得を実装するハンドラー("")
"reconnect.databaseHandler": データベース名の取得を実装するハンドラー("")
"reconnect.tablesHandler": テーブル名の取得を実装するハンドラー("")
"reconnect.mappingHandler": 名前マッピングの取得を実装するハンドラー ("")
"reconnect.usernameHandler": データベースのユーザー名 ("") の取得を実装するハンドラー
"reconnect.passwordHandler": データベースパスワードの取得を実装するハンドラー ("")
"authorization.tableHandler": テーブル認可ルールを実装するハンドラー ("")
"authorization.columnHandler": 列認可ルールを実装するハンドラー ("")
"authorization.pathHandler": パス認可ルールを実装するハンドラー ("")
"authorization.recordHandler": レコード承認フィルター ルールを実装するハンドラー ("")
"validation.handler": 入力値の検証ルールを実装するハンドラー ("")
"validation.types": 型検証を有効にする型。空は「なし」(「すべて」) を意味します。
"validation.tables": 型検証を有効にするテーブル。空は「なし」(「すべて」) を意味します。
"ipAddress.tables": IP アドレス ("") でオーバーライドする列を検索するテーブル
"ipAddress.columns": 作成時に保護し、IP アドレスで上書きする列 ("")
"sanitation.handler": 入力値の衛生ルールを実装するハンドラー ("")
"sanitation.types": タイプの衛生管理を有効にするタイプ。空は「なし」(「すべて」) を意味します。
"sanitation.tables": タイプの衛生管理を有効にするテーブル、空は「なし」(「すべて」) を意味します
"multiTenancy.handler": 単純なマルチテナント ルールを実装するハンドラー ("")
"pageLimits.pages": リスト操作で許可される最大ページ番号 ("100")
"pageLimits.records": リスト操作によって返されるレコードの最大数 ("1000")
"joinLimits. Depth": 結合パスで許可される最大の深さ (長さ) ("3")
"joinLimits.tables": 参加できるテーブルの最大数 ("10")
"joinLimits.records": 結合されたエンティティに対して返されるレコードの最大数 ("1000")
"textSearch.parameter": 検索語 ("search") に使用されるパラメータの名前
"customization.beforeHandler": リクエストのカスタマイズを実装するハンドラー ("")
"customization.afterHandler": レスポンスのカスタマイズを実装するハンドラー ("")
"json.controllers": JSON 文字列を処理するコントローラー ("records,geojson")
"json.tables": JSON 文字列を処理するテーブル ("all")
"json.columns": JSON 文字列を処理する列 ("all")
「xml.types」: XML タイプ属性に追加する必要がある JSON タイプ (「null,array」)
構成でこれらのパラメーターを指定しない場合は、デフォルト値 (括弧内) が使用されます。
以下のセクションでは、組み込みミドルウェアの詳細について説明します。
現在、5 種類の認証がサポートされています。これらはすべて、認証されたユーザーを$_SESSIONスーパー グローバルに保存します。この変数は、誰かが特定のテーブル、列、またはレコードへの読み取りまたは書き込みアクセス権を持つべきかどうかを決定するために、承認ハンドラーで使用できます。次の概要は、有効にできる認証ミドルウェアの種類を示しています。
| 名前 | ミドルウェア | 経由で認証されました | ユーザーは次の場所に保存されます | セッション変数 |
|---|---|---|---|---|
| APIキー | APIキー認証 | 「X-API-Key」ヘッダー | 構成 | $_SESSION['apiKey'] |
| APIキーDB | apiKeyDbAuth | 「X-API-Key」ヘッダー | データベーステーブル | $_SESSION['apiUser'] |
| データベース | データベース認証 | 「/login」エンドポイント | データベーステーブル | $_SESSION['user'] |
| 基本 | 基本認証 | 「認可」ヘッダー | 「.htpasswd」ファイル | $_SESSION['username'] |
| JWT | jwt認証 | 「認可」ヘッダー | アイデンティティプロバイダー | $_SESSION['claims'] |
各認証タイプの詳細については、以下で説明します。
API キー認証は、リクエスト ヘッダーで API キーを送信することで機能します。ヘッダー名のデフォルトは「X-API-Key」で、「apiKeyAuth.header」構成パラメーターを使用して構成できます。有効な API キーは、「apiKeyAuth.keys」構成パラメーター (カンマ区切りリスト) を使用して構成する必要があります。
X-API-Key: 02c042aa-c3c2-4d11-9dae-1a6e230ea95e
認証された API キーは$_SESSION['apiKey']変数に保存されます。
API キー認証ではセッション Cookie が必要または使用されないことに注意してください。
API キー データベース認証は、リクエスト ヘッダー「X-API-Key」(名前は構成可能) で API キーを送信することによって機能します。有効な API キーは、「users」テーブルの「api_key」列からデータベースから読み取られます (両方の名前は構成可能です)。
X-API-Key: 02c042aa-c3c2-4d11-9dae-1a6e230ea95e
認証されたユーザー (そのすべてのプロパティとともに) は$_SESSION['apiUser']変数に保存されます。
API キー データベース認証ではセッション Cookie が必要または使用されないことに注意してください。
データベース認証ミドルウェアは、次の 5 つの新しいルートを定義します。
method path - parameters - description --------------------------------------------------------------------------------------------------- GET /me - - returns the user that is currently logged in POST /register - username, password - adds a user with given username and password POST /login - username, password - logs a user in by username and password POST /password - username, password, newPassword - updates the password of the logged in user POST /logout - - logs out the currently logged in user
ユーザーは、ユーザー名とパスワードをログイン エンドポイントに (JSON 形式で) 送信することでログインできます。認証されたユーザー (そのすべてのプロパティとともに) は$_SESSION['user']変数に保存されます。ユーザーは、空の本文を含む POST リクエストをログアウト エンドポイントに送信することでログアウトできます。パスワードは、users テーブルのパスワード列にハッシュとして保存されます。登録エンドポイントを使用して新しいユーザーを登録できますが、この機能は「dbAuth.registerUser」構成パラメータを使用して有効にする必要があります。
「承認」ミドルウェアを使用してユーザー テーブルへのアクセスを制限することが重要です。そうしないと、すべてのユーザーがアカウントを自由に追加、変更、または削除できます。最小構成を以下に示します。
'middlewares' => 'dbAuth,authorization',
'authorization.tableHandler' => function ($operation, $tableName) {
return $tableName != 'users';
},このミドルウェアはセッション Cookie を使用し、ログイン状態をサーバーに保存することに注意してください。
結合テーブルを含むビューを使用してログインする
ログイン操作では、ビューを usersTable として使用できます。このようなビューは、users テーブルからフィルタリングされた結果を返すことができます (たとえば、 active = true の場合) 、またはテーブル結合を通じて複数のテーブルの結果を返すこともできます。ビューには少なくとも、ユーザー名とパスワード、およびidという名前のフィールドが含まれている必要があります。
ただし、結合テーブルを含むビューは挿入できません (問題 907 を参照)。回避策として、プロパティloginTable を使用して、ログイン用に別の参照テーブルを設定します。 usersTable は、引き続き通常の挿入可能なユーザー テーブルに設定されます。
Wordpress 認証ミドルウェアは 3 つのルートを定義します。
method path - parameters - description --------------------------------------------------------------------------------------------------- GET /me - - returns the user that is currently logged in POST /login - username, password - logs a user in by username and password POST /logout - - logs out the currently logged in user
ユーザーは、ユーザー名とパスワードをログイン エンドポイントに (JSON 形式で) 送信することでログインできます。ユーザーは、空の本文を含む POST リクエストをログアウト エンドポイントに送信することでログアウトできます。 「wpAuth.wpDirectory」構成パラメータを使用して、Wordpress のインストール ディレクトリを指定する必要があります。ミドルウェアは「wp-load.php」を呼び出します。これにより、認可ミドルウェアで次のような Wordpress 機能を使用できるようになります。
wp_get_current_user()
is_user_logged_in()
is_super_admin()
user_can(wp_get_current_user(),'edit_posts');
$_SESSION変数はこのミドルウェアでは使用されないことに注意してください。
基本タイプは、ユーザーとその (ハッシュされた) パスワードをコロン (「:」) で区切って保持するファイル (デフォルトでは「.htpasswd」) をサポートします。パスワードが平文で入力されると、自動的にハッシュ化されます。認証されたユーザー名は$_SESSION['username']変数に保存されます。 「Basic」という単語の後に、コロンで区切られたユーザー名とパスワードを Base64 URL エンコードしたバージョンを含む「Authorization」ヘッダーを送信する必要があります。
Authorization: Basic dXNlcm5hbWUxOnBhc3N3b3JkMQ
この例では、文字列「username1:password1」を送信します。
JWT タイプでは、クレームを含むトークンに署名するために別の (SSO/アイデンティティ) サーバーが必要です。両方のサーバーはシークレットを共有するため、署名したり、署名が有効であることを検証したりできます。クレームは$_SESSION['claims']変数に保存されます。 Base64 URL でエンコードされ、ドットで区切られたトークン ヘッダー、本文、および「Bearer」という単語の後の署名を含む「X-Authorization」ヘッダーを送信する必要があります (JWT の詳細については、こちらをご覧ください)。標準では「Authorization」ヘッダーを使用する必要があると規定されていますが、これは Apache と PHP では問題になります。
X-Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6IjE1MzgyMDc2MDUiLCJleHAiOjE1MzgyMDc2MzV9.Z5px_GT15TRKhJCTHhDt5Z6K6LRDSFnLj8U5ok9l7gw
この例では、署名されたクレームを送信します。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true,
"iat": "1538207605",
"exp": 1538207635
}注意: JWT 実装は、RSA および HMAC ベースのアルゴリズムのみをサポートします。
