【Hasura Docs翻訳】アクセスコントロールの基礎
Hasura公式ドキュメントを翻訳しました Access control basics
前書き
Hasuraのアクセスコントロールの基礎を理解するために、SQLクエリとの共通点を見てみましょう:
このクエリは、既存のテーブルの行と列の要求を定義することにより、正しい結果を返します。Hasuraのルールベースのアクセスコントロールも同様に動きます。Role, Table, Action(insert, update, select and delete)の組み合わせに対して以下の権限を定義します。
行レベルの権限
この権限に基づいて、テーブルの行の一部のアクセスを制限します。行レベルの権限は、基本的にブール式であり、任意の行を評価した時にアクセスが可能かどうか決定されます。これらの権限は、ブール式を作成するために列やセッション変数、静的な値から構成されます。
列レベルの権限
上記に基づいてアクセス可能な行については、この権限ルールに基づいて列の一部を制限します。
詳しくは
全ての構成オプションについては、アクセス許可ルールの構成を参照ください。
例
簡単な例を使用して、アクセスコントロールをみてみましょう
テーブルを作成する
コンソール画面に行き、次のスキーマにしたがってauthorというテーブルを作成します。
author ( id INT PRIMARY KEY, name TEXT )
次に、authorテーブルのInsert Rowタブを使用してサンプルデータを挿入していきます。
アクセス制御なしでクエリを実行する
コンソール画面のGraphQLタブに移動し、次のクエリを実行しください。
query {
author {
id
name
}
}
デフォルトのGraphQLクエリは管理者権限で実行されるため、全ての著者を含んだレスポンスを受け取ることがわかります。
アクセス制御ルールを定義する
次に、authorテーブルにusersに対するアクセスコントロールのルールを定義しましょう。テーブルの権限タブに移動し(Data –> table –> Permissions tab)、以下に示すように権限を定義してください:
この権限のルールは「userとauthorテーブル、select/query操作に対して、id列がセッション値のX-Hasura-User-IDと同じ値である行へのアクセスを許可する」と読みます。
アクセス制御を使用してクエリを実行する
上記と同じクエリを実行してみましょう。ただし、役割とユーザー情報を示すためにX-Hasura-RoleとX-Hasura-User-IDセッション変数も含まれています。これらのセッション変数は、以下で強調表示されているGraphiQLのRequest Headersセクションに渡されます:
ご覧の通り、結果はuserに対するアクセスコントロールのルールに基づきフィルターされています(セッション変数のX-Hasura-Roleによって役割が示されています)。そして、結果はid行が(セッション変数のX-Hasura-User-IDによって示されている)1の値である行に絞られています。
ドキュメントの認証と認可の概要のセクションで説明されているように、認証トークンをこれらのセッション変数に解決するには、認証サービスが必要です。詳細については、 リファレンス-セッション変数を参照してください。
次のステップ
役割とセッション変数の記事を読む: 役割とセッション変数
より詳細な例を参照する:一般的なアクセス制御の例
【Hasura Docs翻訳】Actions 概要
このコンテンツは以下のHasura公式ドキュメントを翻訳したものです
アクションとは
アクションは、カスタムクエリとミューテーションを使用してカスタムビジネスロジックでHasuraのスキーマを拡張する方法です。アクションをHasuraに追加して、データ検証、外部ソースからのデータエンリッチメント、その他の複雑なビジネスロジックなどのさまざまなユースケースを処理できます。

アクションの説明
アクションは以下の部品から構成されています:
Type: アクションのタイプ(queryまたはmutation)Definition: queryやmutationの定義Handler: queryやmutationが実行された時に走らせる処理Kind: 同期または非同期が選択できます。queryアクションの場合、Kindはありません。queryアクションは常に同期されます
Type
アクションには2つのタイプがあります:
Query Action: QueryタイプのアクションはHasuraスキーマのquery rootを拡張します。これは、graphQL queryを通してこのアクションを実行できることを意味します。Queryアクションは、データソースを変更することなくデータソースからデータを取得する際に使用する必要があります。Mutation Action: MutationタイプのアクションはHasuraスキーマのmutation rootを拡張します。 これは、graphQL mutationを通してこのアクションを実行できることを意味します。Mutationアクションは、データソースの状態を変更したい場合やデータを取得したい場合に使用する必要があります。
Definition
アクションの定義は次のもので構成されています:
Action Name: アクション名を付与することによってGraphQLスキーマのqueryまたはmutationとして使用されます。Arguments: 引数は動的な値をqueryやmutationに渡すために使用されます。Response type: このレスポンスタイプは、queryやmutationが返す値です。アクションは、オブジェクトタイプのみ返すことができます。
例えば、次のアクションを考えてみます:
extend type Mutation {
userLogin(username: String!, password: String!): UserInfo
}
この定義では、mutation rootをuserLoginによって拡張しています。
userLoginはアクション名usernameやpasswordはnon-nullableな文字列を許可する引数UserInfoはアクションのレスポンスタイプ
Custom Types
アクションはオブジェクトタイプを返さなければいけません。これは、あなたがカスタムタイプを定義しなければならないことを意味します。
type UserInfo {
accessToken: String!
userId: Int!
}
Handler
一度アクションタイプを定義すると、アクションが実行された時に走らせる処理を細かく指定しないといけません。アクションハンドラと言われるHTTP webhookで実行できます。
Kind
Mutationアクションには2種類あります:
- 同期: 同期アクションはハンドラーからレスポンスを受け取ったあと、クライアントにレスポンスを返します
- 非同期: 非同期アクションはハンドラーからレスポンスを受け取ったあと、クライアントにレスポンスとして
action idを返し、クライアントはaction idを使って実際のレスポンスを購読できます。
Queryアクションはkindを持っていません。常に同期ミューテーションアクションのように動作します。
どのように動くのか
- HasuraはGraphQLクエリまたはミューテーションを受け取り、このリクエストをイベントの付加情報に変換します
- このイベントはキャプチャと永続化されてから、適切な再試行/送信の保証とともにアクションハンドラーに送信されます
- このアクションハンドラーは実行され、イベントとしてキャプチャーされたレスポンスを返却し、再度イベントストアに永続化されます
- このアクションのレスポンスはkindに基づいた同期または非同期的にクライアントに返されます
アクションvsリモートスキーマ
アクションもリモートスキーマもビジネスロジックと共にHasuraを拡張するために使用されます。しかしこれらはユースケースに少し違いがあります。
アクション
アクションはカスタムタイプのためのリゾルバとしてHasuraからRESTエンドポイントを呼び出したい時に使用されます。これらは特に、サーバレス関数をリゾルバーとして設定する際に便利です。
リモートスキーマ
もし、あなたがGraphQL APIを既に持っている場合や自分自身でGraphQLサーバを構築することに抵抗がない場合、リモートスキーマを使用することでカスタムタイプやリゾルバーを追加することができます。



