ロールの定義

このセクションでは、Hasuraによる権限のモデル化ロールへの一般的なアプローチ方法を見ていきます。

従来なら、ユーザーに割り当てられた責任に基づいて複数のロールを検討するでしょう。

slackアプリモデルでは、迅速な分析により複数のロールの可能性が示されます。アプリの users、ワークスペースを制御および管理する workspace owners、ワークスペースを管理する権限のサブセットを持つ workspace admins、channel admins などがあります。しかし、重要な点は、それらはすべて、一部のデータの読み取り / 書き込みの追加権限しかないアプリの users であるということです。そのため、上記の権限レイヤーに対応できる user と呼ばれる単一のロールのみを定義することになります。次のセクションでその方法を見ていきます。

多くの場合、Hasuraではアプリのユーザーは1つのロールしか必要ありません。しかし、データアクセスを制御するために複数のロールが必要になる場合があります。

複数のロールのケース

では、どんなときに権限の定義に複数のロールが使用されるのでしょうか？ユースケースをいくつか紹介しましょう。

ログインと一般公開されているデータ

アプリ内でデータの一部は一般公開されているが、一部はログイン済みのユーザーのみが利用可能な場合、複数のロールが必要となります。slackアプリでは、すべてがログイン済みのユーザーのみ利用可能なものと想定されます。

列への異なるアクセス

誰がログインしたかによってアクセスできる列が異なる場合、複数のロールが使用されます。例えば、slackアプリモデルでは、ワークスペースのオーナーは、機密性が高く、他のユーザーには読み取りアクセスが制限される一部の列を見ることができます。そのため、当然、複数のロールを定義する必要があります。

バックエンドサポート / 管理チーム

アプリに管理者/カスタマーサポート/分析チームがいて、制限なしでテーブル間での読み取りアクセスを必要とする場合、それぞれに個別のロールが与えられます。

上記の制約がない場合、単一のロールで問題ありません。