Pre-function
概要
Pre-function ポリシーは、リクエストが処理される前にユーザーがカスタムスクリプトを実行できるようにします。このポリシーにより、ユーザーはリクエストパラメータ、ヘッダー、およびボディコンテンツを追加、削除、または変換することで、リクエストを動的に変更できます。
Pre-function ポリシーは、一般的に以下の目的で使用されます：
- Data Masking: バックエンドに到達する前に、個人識別番号などの機密データを隠すこと。
- Query String Manipulation: クエリパラメータを動的に変更またはフィルタリングすること。
- Token Validation: 認証およびセキュリティロジックを実装すること。
- Routing Control: リクエスト属性に基づいてルーティングの決定を変更すること。
設定の詳細
Pre-function ポリシーは、ユーザーがスクリプトを書く code editor で構成されています。インターフェースには、以下のコンポーネントが含まれています：
コードエディタ
editor は、ユーザーがAPIリクエストライフサイクルのさまざまな実行フェーズのためにカスタムLuaスクリプトを書いたり修正したりするための主要なエリアです。コードエディタ内には、4つのタブがあります：
- Access: ここに入力されたコードは、アクセスフェーズ中に実行され、ユーザーが認証、ヘッダー、パスの書き換えなどのリクエストレベルのロジックを操作できるようにします。
- Header Filter: クライアントに返される前にレスポンスヘッダーを変更するために使用されます。
- Body Filter: レスポンスボディを操作できるようにし、レスポンスコンテンツを変換またはマスクするのに役立ちます。
- Log: リクエストが処理された後に、リクエストまたはレスポンスデータに基づいてロギング動作を実装するために使用されます。
各タブには専用のコードエディタがあり、開発を迅速化するためのスニペットや例にアクセスできます。
コードは、複数の実行フェーズを利用する場合、各タブ内で別々に記述して保存する必要があります。
スニペット（定義済みコードブロック）
Snippets セクションでは、ユーザーがエディタに挿入できる定義済みのコードブロックを提供します。これにより、ユーザーはコードをゼロから書くことなく、一般的に使用されるリクエストの変更を迅速に実装できます。
スニペットのリスト：
| Snippets | Description |
|---|---|
| JSON パーサー | JSON 形式のリクエストボディを読み込み、処理します。 |
| リクエスト生ボディの取得 | 処理前にリクエストボディ全体を取得します。 |
| サービスリクエスト生ボディの設定 | リクエストボディを変更し、バックエンドに転送する前に修正します。 |
| リクエストメソッドの取得 | HTTP メソッド（GET、POST など）を取得します。 |
| リクエストパスの取得 | 完全なリクエストパスを取得します。 |
| リクエストヘッダーの取得 | 特定のリクエストヘッダーから値を抽出します。 |
| リクエストヘッダーの設定 | リクエストヘッダーを動的に変更または追加します。 |
| レスポンス終了の設定 | リクエストを終了し、カスタムレスポンスを返します。 |
| サービスホストの設定 | 宛先サーバーを動的に変更します。 |
| サービスリクエストスキームの設定 | リクエストスキーム（http または https）を変更します。 |
| サービスリクエストパスの設定 | リクエストパスを変更し、バックエンドに送信する前に修正します。 |
例のセクション
このセクションには、Pre-function ポリシーの実用的な実装を示す定義済みの例スクリプトが含まれています。これらの例は、ユーザーが一般的なシナリオを迅速に実装するためのテンプレートとして機能します。
例のリスト：
| Examples | Description |
|---|---|
| マスキングデータ | リクエストペイロード内の機密情報をマスクします。クエリ文字列に値として現れた場合、韓国の住民登録番号を「SSN-DATA」に置き換え、ルーティングを続行します。 |
| クエリ文字列操作 | "service"キーとその対応する値を除くすべてのクエリ文字列を削除します。 バックエンドルーティング条件に基づいてパラメータをフィルタリングします: - ルーティング対象のバックエンドアドレスがAの場合、すべてのクエリパラメータは完全に削除されます。 - ただし、ルーティング対象のバックエンドアドレスがBの場合、特定のクエリパラメータのセットのみが許可され、他は破棄されます。 |
| トークン検証 | "Authorization: bearer xxxxxxxx"トークンに対してカスタム検証を正規表現を使用して実装します。また、特定のメソッド + パスの組み合わせはベアラートークンの検証を行いません。 |
| ルーティング | ユーザーがコードを記述できるようにし、状況に応じてルーティングを続行するか、即座に失敗を処理できるようにします。 |
ユーザーはコードエディタ内でスクリプトを直接修正するか、事前定義されたスニペットを使用できます。例をクリックするとポップアップエディタが開き、さらなるカスタマイズが可能になります。
前処理ポリシーに関するよくある質問
- When does Pre-function execute in the API lifecycle?
前処理は、選択された実行フェーズに応じて、リクエストまたはレスポンス処理中にsynchronouslyを実行します。
実行はonly after a request reaches the API policy chainで発生し、バックエンドに転送される前またはクライアントに返される前に行われます。
- 4 separate execution phase of Pre-function detailed as below. Logic placed in the wrong phase will not work as expected.
アクセスフェーズ
- 実行される before routing to the backend
- 認証、検証、ヘッダー/クエリ/パスの操作、およびルーティング制御に使用される
- ここがほとんどのリクエストレベルのロジックを実装すべき場所です
ヘッダーフィルターフェーズ
- 実行される before response headers are sent to the client
- 応答ヘッダーを変更するためのみに使用される
ボディフィルターフェーズ
- 実行される while processing the response body
- 応答ペイロードをマスキングまたは変換するために使用される
ログフェーズ
- 実行される after the request is completed
- ロギングと可観測性のためのみに使用される
- ここでの変更は not リクエストまたは応答の動作に影響を与えます
- Can scripts in different tabs share data or variables?
いいえ。
各実行フェーズ：
- 独立して実行される
- 他のタブと自動的に変数や状態を共有しない
- リクエスト間で持続的なメモリを持たない
タブ間で full isolation を仮定する必要がありますが、サポートされているコンテキストメカニズムを通じて明示的に処理されない限り。
- What can’t (or shouldn’t) Pre-function do?
プレファンクションは not designed to です：
- リクエスト間でデータを持続させる
- 長時間実行またはブロッキング操作を実行する
- 専用の認証または認可ポリシーを完全に置き換える
- バックエンド内部に直接アクセスする
- 秘密情報や資格情報を安全に保存する
- Can Pre‑function be used to block or reject requests?
はい。
Set Response Exit スニペットを Access phase で使用して：
- リクエストの実行を即座に停止する
- カスタムステータスコードと応答ボディを返す
- バックエンド呼び出しを避ける
これは、検証または認可の失敗を処理するための推奨方法です。