ユーザーのための権限

Slackアプリは、ユーザーを中心に展開します。まず、CRUD操作のためのアプリのユーザーの権限ルールを設定します。

権限

Slackのログイン済みユーザーが読み取れるのは、どんなユーザーデータですか？

すべてのログイン済みユーザーは、ログイン済みユーザーと同じワークスペースに所属するユーザーのユーザーデータを読み取ることができます。

要件は、以下のようになります。

• 自分のユーザーデータを読み取れます。
• 自分がメンバーであるワークスペースに参加している他のユーザーのユーザーデータを読み取ることができます。

これは、ユーザーテーブルでレコードにアクセスしようとしている人は id = X-Hasura-User-Id に属しているか、同じワークスペース workspace_members.user_id = X-Hasura-User-Id に参加している必要があることを示す典型的なブール式です。

行レベル選択

上記のステートメントの拡張された有効なブール式は、以下のようになります。

Copy
{
  "_or": [
    {
      "id": {
        "_eq": "X-Hasura-User-Id"
      }
    },
    {
      "workspace_members": {
        "user_id": {
          "_eq": "X-Hasura-User-Id"
        }
      }
    }
  ]
}

列レベル選択

ユーザーがアクセスすると想定される行を除外した後、読み取りが許可されるフィールドを除外する必要があります。ユーザーのみに制限する必要がある機密データはないため、password フィールド以外の、users テーブル内のすべての列は認証されたユーザーなら誰でもアクセスできます。

読み取りアクセスが完了しました。次に、ユーザーが作成、更新、または削除できる書き込みアクセスを紹介します。

権限を挿入する

アプリのユーザーは、users テーブルに直接挿入できますか？いいえ。ユーザーは、ユーザーの登録、検証、ウェルカムメールのトリガーなどを処理する認証サーバーを経由するアプリにサインアップします。そのため、管理者ロールにアクセスできる認証サーバーが、users テーブルポスト検証にレコードを挿入して、適切なトークンを生成します。ユーザーロールの挿入操作の権限の定義はスキップできます。

権限

users テーブル内の既存のデータを更新できるのは誰ですか？

アプリの認証されたユーザーとして、iは自分の個人データのみ更新できる必要があります。

行レベル更新

上記の条件は、以下の式になります。

Copy
{
  "id": {
    "_eq": "X-Hasura-User-Id"
  }
}

列の id が認証されたユーザーのid値（X-Hasura-User-Id）と一致する場合のみ、行を更新します

列レベル更新

ユーザーがアプリから直接更新できる列を修正する必要があります。そのため、ユーザーに自分の id、email、および created_at 値の更新を許可しないでください。また、password 列の直接変更も制限します。それは、更新前に必要な検証を行う認証サーバーに任せるためです。

権限を削除する

ユーザーがアプリから直接自分のユーザーレコードを削除できないようにしたいので、この操作のルールの定義はスキップできます。これは、ユーザーアカウントの削除のためのユーザー管理ポスト検証を処理するAuthサーバーによって行われると想定します。

他のロールの可能性

上記のルールはすべて、ユーザーロールに適用されます。ただし、ユーザーに対してプライベートであり、他のユーザーが読み取ることを意図しないフィールドがあるとします。例えば、現在のモデルで、phone_number フィールドはパブリックであると想定します。ユーザーに対してプライベートであることが要件である場合、新しいロールを作成する必要があります。これを me と呼び、 phone_number列がない選択権限のルールを定義しましょう。

行レベル選択ルールは、以下のようになります。

Copy
{
  "id": {
    "_eq": "X-Hasura-User-Id"
  }
}

そして、列レベル権限はロール me に対して同じですが、ロール user には phone_number 列へのアクセス権がありません。