すべての Google ドライブのファイル、フォルダ、共有ドライブには、
permissions リソースが関連付けられています。各リソース
は、特定の
type(user、
group、domain、anyone)と
role(owner、
organizer、fileOrganizer、writer、commenter、reader)の権限を識別します。たとえば、
ファイルには、特定のユーザー(type=user)に読み取り専用
アクセス権(role=reader)を付与する権限と、特定の
グループ(type=group)のメンバーにファイルにコメントを追加する権限(role=commenter)が設定されている場合があります。
ロールの一覧と、各ロールで許可される操作については、ロール と権限をご覧ください。
権限の仕組み
フォルダの権限リストは下位に伝播します。すべての子ファイルとフォルダは、親から権限を継承します。権限または階層が変更されると、ネストされたすべてのフォルダに再帰的に伝播されます。たとえば、ファイルがフォルダに存在し、そのフォルダが別のフォルダ内に移動した場合、新しいフォルダの権限がファイルに伝播されます。新しいフォルダでファイル ユーザーに「書き込み」などの新しいロールが付与されると、古いロールはオーバーライドされます。
逆に、ファイルがフォルダから role=writer を継承し、「閲覧者」ロールを提供する別のフォルダに移動すると、ファイルは role=reader を継承します。
継承された権限は、どのアイテムでも削除または縮小できません。代わりに、これらの 権限は、権限の発生元の親で調整するか、階層内の フォルダで アクセス制限付きの設定を有効にする必要があります。
継承された権限は、アイテムで増やすことができます。子の権限が増加した場合、新しい親の権限が子よりも大きくない限り、親の権限を変更しても子の権限には影響しません。
同じファイルに対する権限操作の同時実行はサポートされていません。最後の更新のみが適用されます。
ファイルの機能について
permissions リソースは、最終的に
現在のユーザーがファイルまたはフォルダに対してアクションを実行できるかどうかを決定するものではありません。代わりに、files リソースには、ファイルまたはフォルダに対してアクションを実行できるかどうかを示すブール値の capabilities フィールドのコレクションが含まれています。Google Drive API は、ファイルまたはフォルダに関連付けられた現在のユーザーの permissions リソースに基づいて、これらのフィールドを設定します。
たとえば、Alex がアプリにログインしてファイルを共有しようとすると、Alex のロールでファイルの権限が確認されます。ロールでファイルの共有が許可されている場合、canShare などのファイルに関連する capabilities はロールに応じて設定されます。Alex がファイルを共有しようとすると、アプリは capabilities をチェックして、canShare が true に設定されていることを確認します。
ファイルの機能を取得する
アプリがファイルを開くときは、ファイルの機能を確認し、現在のユーザーの権限を反映するように UI を表示する必要があります。たとえば、ユーザーがファイルに対する canComment 機能を持っていない場合、UI でコメント機能が無効になっている必要があります。
機能を確認するには、get
メソッドを files リソースの fileId
パスパラメータと fields パラメータを capabilities フィールドに設定して呼び出します。
パラメータを使用してフィールドを返す方法について詳しくは、
特定のフィールドを返すをご覧ください。fields
次のコードサンプルは、ユーザー権限を確認する方法を示しています。レスポンスでは、ユーザーがファイルに対して持つ機能のリストが返されます。各機能は、ユーザーが実行できるきめ細かいアクションに対応しています。一部のフィールドは、共有ドライブ内のアイテムにのみ入力されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID?fields=capabilitiesレスポンス
{ "capabilities": { "canAcceptOwnership": false, "canAddChildren": false, "canAddMyDriveParent": false, "canChangeCopyRequiresWriterPermission": true, "canChangeItemDownloadRestriction": true, "canChangeSecurityUpdateEnabled": false, "canChangeViewersCanCopyContent": true, "canComment": true, "canCopy": true, "canDelete": true, "canDisableInheritedPermissions": false, "canDownload": true, "canEdit": true, "canEnableInheritedPermissions": true, "canListChildren": false, "canModifyContent": true, "canModifyContentRestriction": true, "canModifyEditorContentRestriction": true, "canModifyOwnerContentRestriction": true, "canModifyLabels": true, "canMoveChildrenWithinDrive": false, "canMoveItemIntoTeamDrive": true, "canMoveItemOutOfDrive": true, "canMoveItemWithinDrive": true, "canReadLabels": true, "canReadRevisions": true, "canRemoveChildren": false, "canRemoveContentRestriction": false, "canRemoveMyDriveParent": true, "canRename": true, "canShare": true, "canTrash": true, "canUntrash": true } }
ドライブ リソースの共有シナリオ
共有シナリオには次の 5 種類があります。
マイドライブ内のファイルを共有するには、
role=writerまたはrole=ownerが必要です。ファイルの
writersCanShareブール値がfalseに設定されている場合は、role=ownerが必要です。role=writerのユーザーが有効期限の日時で管理される一時的なアクセス権を持っている場合、ファイルを共有することはできません。詳しくは、有効期限を設定してアイテムへのアクセスを制限するをご覧ください。
マイドライブ内のフォルダを共有するには、
role=writerまたはrole=ownerが必要です。ファイルの
writersCanShareブール値がfalseに設定されている場合は、より権限の緩いrole=ownerが必要です。一時的なアクセス権(有効期限の日時で管理)は、
role=readerのフォルダでのみ許可されます。詳しくは、 有効期限を設定してアイテムへのアクセスを制限するをご覧ください。
共有ドライブ内のファイルを共有するには、
role=writer、role=fileOrganizer、またはrole=organizerが必要です。writersCanShare設定は、共有ドライブ内のアイテムには適用されません。常にtrueに設定されているものとして扱われます。
共有ドライブ内のフォルダを共有するには、
role=organizerが必要です。- 共有ドライブの
sharingFoldersRequiresOrganizerPermission制限がfalseに設定されている場合、role=fileOrganizerのユーザーは、その共有ドライブ内のフォルダを共有できます。
- 共有ドライブの
共有ドライブのメンバーシップを管理するには、
role=organizerが必要です。共有ドライブのメンバーになれるのは、ユーザーとグループのみです。
fields パラメータを使用する
レスポンスで返すフィールドを指定する場合は、
fields system
parameter
を permissions リソースの任意のメソッドで設定します。fields パラメータを省略すると、サーバーはメソッド固有のデフォルトのフィールド セットを返します。たとえば、list メソッドは、各ファイルの id、type、kind、role フィールドのみを返します。別のフィールドを返す方法については、特定のフィールドを返すをご覧ください。
権限を作成する
権限を作成するには、次の 2 つのフィールドが必要です。
type:typeは、権限のスコープ(user、group、domain、anyone)を識別します。type=userの権限は特定のユーザーに適用されますが、type=domainの権限は特定のドメイン内のすべてのユーザーに適用されます。role:roleフィールドは、typeが実行できるオペレーションを識別します。たとえば、type=userとrole=readerの権限は、特定のユーザーにファイルまたはフォルダへの読み取り専用アクセス権を付与します。また、type=domainとrole=commenterの権限を使用すると、ドメイン内のすべてのユーザーがファイルにコメントを追加できます。ロールの一覧と、各ロールで許可される操作については、 ロールと権限をご覧ください。
type=user または type=group の権限を作成する場合は、特定のユーザーまたはグループを権限に関連付けるために emailAddress も指定する必要があります。
type=domain の権限を作成する場合は、
domain を権限に関連付けるために
特定のドメインも指定する必要があります。
権限を作成するには:
- 関連付けられたファイルまたはフォルダの
fileIdパスパラメータを指定して、createメソッドをpermissionsリソースで使用します。 - リクエストの本文で、
typeとroleを指定します。 type=userまたはtype=groupの場合は、emailAddressを指定します。type=domainの場合は、domainを指定します。
次のコードサンプルは、権限を作成する方法を示しています。レスポンスでは、割り当てられた permissionId を含む permissions リソースのインスタンスが返されます。
リクエスト
POST https://www.googleapis.com/drive/v3/files/FILE_ID/permissions{ "requests": [ { "type": "user", "role": "commenter", "emailAddress": "alex@altostrat.com" } ] }
レスポンス
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "commenter"
}対象グループを使用する
対象グループとは、ユーザーにアイテムの共有先として推奨できるグループ(部署やチームなど)のことです。ユーザーに組織全体ではなく一部の限られたユーザー グループとアイテムを共有するよう推奨できます。対象グループを使用すると、データのセキュリティとプライバシーを強化し、ユーザーが適切に共有しやすくなります。詳しくは、対象グループ についてをご覧ください。
対象グループを使用するには:
Google 管理コンソールで、メニュー アイコン > [ディレクトリ] > [対象グループ] に移動します。
このタスクを行うには、特権管理者権限を持つアカウントでログインする必要があります。
[**対象グループ**] リストで、対象グループの名前をクリックします。対象グループを作成するには、対象グループを作成する をご覧ください。
対象グループの URL
https://admin.google.com/ac/targetaudiences/IDから一意の ID をコピーします。権限を作成し、
type=domainを使用してdomainフィールドをID.audience.googledomains.comに設定します。
ユーザーが対象グループを操作する方法については、リンク共有のユーザー エクスペリエンスをご覧ください。
権限を取得する
権限を取得するには、get メソッド
を permissions リソースで、
fileId と permissionId パスパラメータを指定して使用します。権限
ID がわからない場合は、すべての権限を一覧表示するには、list メソッドを使用します。
次のコードサンプルは、ID で権限を取得する方法を示しています。レスポンスでは、permissions リソースのインスタンスが返されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissionsPERMISSION_ID
レスポンス
{
"kind": "drive#permissionList",
"permissions": [
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "commenter"
}
]
}すべての権限を一覧表示する
ファイル、フォルダ、共有ドライブの権限を一覧表示するには、fileId パスパラメータを指定して、permissions リソースの list メソッドを使用します。
次のクエリ パラメータを渡して、権限の ページネーションをカスタマイズしたり、権限をフィルタしたりします。
pageSize: ページごとに返す権限の最大数。共有ドライブ内のファイルに設定されていない場合、最大 100 件の結果が返されます。共有ドライブにないファイルに設定されていない場合は、リスト全体が返されます。pageToken: 前回のリスト呼び出しで受信したページトークン。このトークンを指定すると、次のページを取得できます。supportsAllDrives: リクエスト元のアプリがマイドライブと共有ドライブの両方をサポートしているかどうか。useDomainAdminAccess: ドメイン管理者としてリクエストを発行するには、trueに設定します。fileIdパラメータが共有ドライブを参照し、リクエスタが共有ドライブが属するドメインの管理者である場合。詳しくは、ドメイン管理者として共有ドライブを 管理するをご覧ください。includePermissionsForView: レスポンスに含める追加ビューの権限。publishedのみがサポートされています。
次のコードサンプルは、すべての権限を取得する方法を示しています。レスポンスでは、ファイル、フォルダ、共有ドライブの権限のリストが返されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissionsレスポンス
{
"kind": "drive#permissionList",
"permissions": [
{
"id": "PERMISSION_ID",
"type": "user",
"kind": "drive#permission",
"role": "commenter"
}
]
}権限を更新する
ファイルまたはフォルダの権限を更新するには、割り当てられたロールを変更します。ロールのソースの確認について詳しくは、ロールのソースを特定する をご覧ください。
関連付けられたファイル、フォルダ、共有ドライブに
fileIdpath パラメータを設定し、変更する権限にpermissionIdパス パラメータを設定して、permissionsリソースのupdateメソッドを呼び出します。permissionIdを確認するには、fileIdパスパラメータを指定して、permissionsリソースのlistメソッド を使用します。リクエストで、新しい
roleを特定します。
ユーザーまたはグループがすでにメンバーであっても、共有ドライブ内の個々のファイルまたはフォルダに権限を付与できます。たとえば、Alex は共有ドライブのメンバーシップの一部として role=commenter を持っています。ただし、アプリは共有ドライブ内のファイルに対して role=writer を Alex に付与できます。この場合、新しいロールはメンバーシップを通じて付与されたロールよりも権限が緩いため、新しい権限がファイルまたはフォルダの有効なロールになります。
更新はパッチ セマンティクスで適用できます。つまり、リソースの一部を変更できます。リクエストで変更するフィールドを明示的に設定する必要があります。リクエストに含まれていないフィールドは、既存の値を保持します。詳しくは、部分リソースの操作をご覧ください。
次のコードサンプルは、ファイルまたはフォルダの権限を commenter から writer に変更する方法を示しています。レスポンスでは、permissions リソースのインスタンスが返されます。
リクエスト
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
{
"role": "writer"
}レスポンス
{
"kind": "drive#permission",
"id": "PERMISSION_ID",
"type": "user",
"role": "writer"
}ロールのソースを特定する
ファイルまたはフォルダのロールを変更するには、ロールのソースを知る必要があります。 共有ドライブの場合、ロールのソースは、共有ドライブのメンバーシップ、フォルダのロール、ファイルのロールに基づく場合があります。
共有ドライブまたはそのドライブ内のアイテムのロールのソースを特定するには、
fileId パスパラメータと
permissionId パスパラメータを指定し、fields パラメータを
permissionDetails フィールドに設定して、
permissions リソースの get メソッドを呼び出します。
permissionId を確認するには、
list メソッドを permissions
リソースの fileId パスパラメータとともに使用します。list リクエストで permissionDetails
フィールドを取得するには、fields パラメータを
permissions/permissionDetails に設定します。
このフィールドには、ユーザー、グループ、ドメインの継承されたファイル権限と直接的なファイル権限がすべて列挙されます。
次のコードサンプルは、ロールのソースを特定する方法を示しています。レスポンスでは、permissions リソースの permissionDetails が返されます。inheritedFrom フィールドには、権限が継承されたアイテムの ID が表示されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID?fields=permissionDetails&supportsAllDrives=true
レスポンス
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}バッチ リクエストで複数の権限を更新する
複数の権限を変更するには、バッチ リクエストを使用することを強くおすすめします。
クライアント ライブラリを使用してバッチ権限を変更する例を次に示します。
Java
Python
Node.js
PHP
.NET
権限を削除する
ファイルまたはフォルダへのアクセスを取り消すには、
delete メソッドを
permissions リソースで呼び出し、fileId と
permissionId パスパラメータを設定して権限を削除します。
継承された権限を取り消すことはできません。代わりに、親フォルダの権限を更新または削除します。フォルダの権限を削除すると、子アイテムの同等のアクセス権も取り消されます。
親と比較して権限を減らすには、 アクセス制限付きの設定を使用する必要があります。
次のコードサンプルは、permissionId を削除してアクセスを取り消す方法を示しています。成功した場合、レスポンスの本文は空の JSON オブジェクトになります。権限が削除されたことを確認するには、fileId パスパラメータを指定して、permissions リソースの list メソッドを使用します。
リクエスト
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID/permissions/PERMISSION_ID
有効期限を設定してアイテムへのアクセスを制限する
機密性の高いプロジェクトで作業している場合は、一定期間後にドライブ内の特定のアイテムへのアクセスを制限することが必要になることがあります。ファイルとフォルダの場合は、有効期限を設定して、そのアイテムへのアクセスを制限または削除できます。
有効期限を設定するには:
createメソッドをpermissionsリソースで使用し、expirationTimeフィールド(他の必須フィールドとともに)を設定します。詳しくは、 権限を作成するをご覧ください。updateメソッドをpermissionsリソースで使用し、expirationTimeフィールド( 他の必須フィールドとともに)を設定します。詳しくは、権限を 更新するをご覧ください。
The
expirationTime
フィールドは、RFC 3339
の日時を使用して権限の有効期限を示します。有効期限には次の制限があります。
- ユーザー権限とグループ権限にのみ設定できます。
- 時刻は未来である必要があります。
- 時刻は 1 年以上先にはできません。
- フォルダの有効期限付きのアクセス権を付与できるのは、
readerロールのみです。
有効期限について詳しくは、次の記事をご覧ください。
関連トピック
- 保留中のアクセス提案を管理する
- アクセス制限付きフォルダとアクセス制限のないフォルダを管理する
- ファイルのオーナー権限を譲渡する
- ファイル コンテンツを保護する
- リソースキーを使用してリンク共有ドライブ ファイルにアクセスする
- ロールと権限