Chaque fichier, dossier et Drive partagé Google Drive est associé à des ressources permissions
. Chaque ressource identifie l'autorisation pour un type
(user
, group
, domain
, anyone
) et un role
(owner
, organizer
, fileOrganizer
, writer
, commenter
, reader
) spécifiques. Par exemple, un fichier peut avoir une autorisation accordant à un utilisateur spécifique (type=user
) un accès en lecture seule (role=reader
), tandis qu'une autre autorisation permet aux membres d'un groupe spécifique (type=group
) d'ajouter des commentaires à un fichier (role=commenter
).
Pour obtenir la liste complète des rôles et des opérations autorisées par chacun d'eux, consultez la section Rôles et autorisations.
Scénarios de partage de ressources Drive
Il existe cinq types de scénarios de partage différents:
Pour partager un fichier dans Mon Drive, l'utilisateur doit disposer de
role=writer
ou derole=owner
.Si la valeur booléenne
writersCanShare
est définie surfalse
pour le fichier, l'utilisateur doit disposer derole=owner
.Si l'utilisateur avec
role=writer
dispose d'un accès temporaire régi par une date et une heure d'expiration, il ne peut pas partager le fichier. Pour en savoir plus, consultez Définir une date d'expiration pour limiter l'accès aux fichiers.
Pour partager un dossier dans Mon Drive, l'utilisateur doit disposer de
role=writer
ourole=owner
.Si la valeur booléenne
writersCanShare
est définie surfalse
pour le fichier, l'utilisateur doit disposer de l'role=owner
plus permissive.L'accès temporaire (régi par une date et une heure d'expiration) n'est pas autorisé sur les dossiers Mon Drive avec
role=writer
. Pour en savoir plus, consultez Définir une date d'expiration pour limiter l'accès aux fichiers.
Pour partager un fichier dans un Drive partagé, l'utilisateur doit disposer des autorisations
role=writer
,role=fileOrganizer
ourole=organizer
.- Le paramètre
writersCanShare
ne s'applique pas aux éléments des Drive partagés. Il est traité comme s'il était toujours défini surtrue
.
- Le paramètre
Pour partager un dossier dans un Drive partagé, l'utilisateur doit disposer de
role=organizer
.- Si la restriction
sharingFoldersRequiresOrganizerPermission
d'un Drive partagé est définie surfalse
, les utilisateurs disposant derole=fileOrganizer
peuvent partager des dossiers dans ce Drive partagé.
- Si la restriction
Pour gérer l'appartenance à un Drive partagé, l'utilisateur doit disposer de
role=organizer
. Seuls les utilisateurs et les groupes peuvent être membres de Drive partagés.
Définir une date d'expiration pour limiter l'accès aux fichiers
Lorsque vous travaillez avec des personnes sur un projet sensible, il peut être préférable de restreindre leur accès à certains fichiers dans Drive après un certain temps. Pour les fichiers dans le dossier Mon Drive, vous pouvez définir une date d'expiration afin d'en limiter l'accès ou d'y mettre fin.
Pour définir la date d'expiration:
Utilisez la méthode
create()
sur la ressourcepermissions
et définissez le champexpirationTime
(avec les autres champs obligatoires). Pour en savoir plus, consultez la section Créer une autorisation.Utilisez la méthode
update()
sur la ressourcepermissions
et définissez le champexpirationTime
(avec les autres champs obligatoires). Pour en savoir plus, consultez Modifier les autorisations.
Le champ expirationTime
indique la date d'expiration de l'autorisation à l'aide de la date-heure RFC 3339. Les délais d'expiration sont soumis aux restrictions suivantes:
- Elles ne peuvent être définies que sur les autorisations des utilisateurs et des groupes.
- L'heure doit être située dans le futur.
- L'heure ne doit pas être postérieure de plus d'un an à la date du jour.
Pour en savoir plus sur la date d'expiration, consultez les articles suivants:
Propagation des autorisations
Les listes d'autorisations d'un dossier se propagent vers le bas, et tous les fichiers et dossiers enfants héritent des autorisations du parent. Chaque fois que les autorisations ou la hiérarchie sont modifiées, la propagation se produit de manière récursive dans tous les dossiers imbriqués. Par exemple, si un fichier existe dans un dossier et que ce dossier est ensuite déplacé dans un autre dossier, les autorisations du nouveau dossier se propagent au fichier. Si le nouveau dossier attribue un nouveau rôle à l'utilisateur du fichier, tel que "rédacteur", il remplace son ancien rôle.
À l'inverse, si un fichier hérite de role=writer
à partir d'un dossier et est déplacé vers un autre dossier qui fournit un rôle de "lecteur", le fichier hérite désormais de role=reader
.
Vous ne pouvez pas supprimer les autorisations héritées d'un fichier ou d'un dossier dans un Drive partagé. Au lieu de cela, ces autorisations doivent être ajustées sur le parent direct ou indirect dont elles ont été héritées. Vous pouvez supprimer les autorisations héritées des éléments dans "Mon Drive" ou "Partagés avec moi".
À l'inverse, les autorisations héritées peuvent être remplacées pour un fichier ou un dossier dans My Drive. Par conséquent, si un fichier hérite de role=writer
à partir d'un dossier "Mon Drive", vous pouvez définir role=reader
sur le fichier pour réduire son niveau d'autorisation.
Fonctionnalités
La ressource permissions
ne détermine pas en définitive la capacité de l'utilisateur actuel à effectuer des actions sur un fichier ou un dossier. À la place, la ressource files
contient un ensemble de champs capabilities
booléens utilisés pour indiquer si une action peut être effectuée sur un fichier ou un dossier. L'API Google Drive définit ces champs en fonction de la ressource d'autorisations de l'utilisateur actuel associée au fichier ou au dossier.
Par exemple, lorsqu'Alex se connecte à votre application et tente de partager un fichier, les autorisations de son rôle sur le fichier sont vérifiées. Si le rôle lui permet de partager un fichier, les capabilities
associés au fichier, tels que canShare
, sont renseignés par rapport au rôle. Si Alex souhaite partager le fichier, votre application vérifie capabilities
pour s'assurer que canShare
est défini sur true
.
Pour obtenir un exemple de récupération du fichier capabilities
, consultez la section Vérifier les autorisations utilisateur.
Créer une autorisation
Les deux champs suivants sont nécessaires lors de la création d'une autorisation:
type
:type
identifie le champ d'application de l'autorisation (user
,group
,domain
ouanyone
). Une autorisation avectype=user
s'applique à un utilisateur spécifique, tandis qu'une autorisation avectype=domain
s'applique à tous les membres d'un domaine spécifique.role
: le champrole
identifie les opérations que letype
peut effectuer. Par exemple, une autorisation avectype=user
etrole=reader
accorde à un utilisateur spécifique un accès en lecture seule au fichier ou au dossier. Une autorisation avectype=domain
etrole=commenter
permet à tous les membres du domaine d'ajouter des commentaires à un fichier. Pour obtenir la liste complète des rôles et des opérations autorisées par chacun d'eux, consultez la section Rôles et autorisations.
Lorsque vous créez une autorisation où type=user
ou type=group
, vous devez également fournir un emailAddress
pour associer l'utilisateur ou le groupe spécifique à l'autorisation.
Lorsque vous créez une autorisation où type=domain
, vous devez également fournir un domain
pour associer un domaine spécifique à l'autorisation.
Pour créer une autorisation:
- Utilisez la méthode
create()
avec le paramètre de cheminfileId
pour le fichier ou le dossier associé. - Dans le corps de la requête, spécifiez
type
etrole
. - Si la valeur est
type=user
outype=group
, fournissez unemailAddress
. Si la valeur esttype=domain
, indiquez undomain
.
Afficher un exemple
L'exemple de code suivant montre comment créer une autorisation. La réponse renvoie une instance d'une ressource Permission
, y compris l'permissionId
attribué.
Requête
POST https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
{ "requests": [ { "type": "user", "role": "commenter", "emailAddress": "alex@altostrat.com" } ] }
Response (Réponse)
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "commenter"
}
Utiliser des audiences cibles
Les audiences cibles sont des groupes de personnes, comme des services ou des équipes, que vous pouvez recommander aux utilisateurs ayant l'intention de partager des éléments. Vous pouvez encourager les utilisateurs à partager des éléments avec une audience spécifique ou restreinte plutôt que l'ensemble de votre organisation. Les audiences cibles peuvent vous aider à renforcer la sécurité et la confidentialité de vos données, et à faciliter le partage approprié par les utilisateurs. Pour en savoir plus, consultez la section À propos des audiences cibles.
Pour utiliser des audiences cibles:
Dans la console d'administration Google, accédez à Menu > Annuaire > Audiences cibles.
Pour ce faire, vous devez être connecté avec un compte disposant de droits de super-administrateur.
Dans la liste Audiences cibles, cliquez sur le nom de l'audience cible. Pour créer une audience cible, consultez Créer une audience cible.
Copiez l'ID unique à partir de l'URL de l'audience cible:
https://admin.google.com/ac/targetaudiences/ID
.Créez une autorisation avec
type=domain
, puis définissez le champdomain
surID.audience.googledomains.com
.
Pour voir comment les utilisateurs interagissent avec les audiences cibles, consultez Expérience utilisateur pour le partage de liens.
Récupérer toutes les autorisations d'un fichier, d'un dossier ou d'un Drive partagé
Utilisez la méthode list()
sur la ressource permissions
pour récupérer toutes les autorisations d'un fichier, d'un dossier ou d'un Drive partagé.
Afficher un exemple
L'exemple de code suivant montre comment obtenir toutes les autorisations. La réponse renvoie une liste d'autorisations.
Requête
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
Response (Réponse)
{
"kind": "drive#permissionList",
"permissions": [
{
"id": "PERMISSION_ID
",
"type": "user",
"kind": "drive#permission",
"role": "commenter"
}
]
}
Vérifier les autorisations des utilisateurs
Lorsque votre application ouvre un fichier, elle doit vérifier ses fonctionnalités et afficher l'UI pour refléter les autorisations de l'utilisateur actuel. Par exemple, si l'utilisateur ne dispose pas d'une fonctionnalité canComment
sur le fichier, la possibilité de commenter doit être désactivée dans l'interface utilisateur.
Pour en savoir plus sur capabilities
, consultez la section Fonctionnalités.
Pour vérifier les fonctionnalités, appelez la méthode get()
sur la ressource files
avec le paramètre de chemin fileId
et le paramètre fields
défini sur le champ capabilities
. Pour en savoir plus sur le renvoi de champs à l'aide du paramètre fields
, consultez Renvoyer des champs spécifiques pour un fichier.
Afficher un exemple
L'exemple de code suivant montre comment vérifier les autorisations de l'utilisateur. La réponse renvoie la liste des fonctionnalités dont dispose l'utilisateur sur le fichier. Chaque capacité correspond à une action précise qu'un utilisateur peut effectuer. Certains champs ne sont renseignés que pour les éléments de Drive partagés.
Requête
GET https://www.googleapis.com/drive/v3/files/FILE_ID
?fields=capabilities
Response (Réponse)
{ "capabilities": { "canAcceptOwnership": false, "canAddChildren": false, "canAddMyDriveParent": false, "canChangeCopyRequiresWriterPermission": true, "canChangeSecurityUpdateEnabled": false, "canComment": true, "canCopy": true, "canDelete": true, "canDownload": true, "canEdit": true, "canListChildren": false, "canModifyContent": true, "canModifyContentRestriction": true, "canModifyLabels": true, "canMoveChildrenWithinDrive": false, "canMoveItemOutOfDrive": true, "canMoveItemWithinDrive": true, "canReadLabels": true, "canReadRevisions": true, "canRemoveChildren": false, "canRemoveMyDriveParent": true, "canRename": true, "canShare": true, "canTrash": true, "canUntrash": true } }
Déterminer la source de rôle pour les fichiers et dossiers de Drive partagé
Pour modifier le rôle d'un fichier ou d'un dossier, vous devez connaître la source du rôle. Pour les Drive partagés, la source d'un rôle peut être basée sur l'appartenance au Drive partagé, le rôle sur un dossier ou le rôle sur un fichier.
Pour déterminer la source de rôle d'un lecteur partagé ou d'éléments de ce lecteur, appelez la méthode get()
sur la ressource permissions
avec les paramètres de chemin fileId
et permissionId
, et le paramètre fields
défini sur le champ permissionDetails
.
Pour trouver le permissionId
, utilisez la méthode list()
sur la ressource permissions
avec le paramètre de chemin fileId
. Pour extraire le champ permissionDetails
de la requête list
, définissez le paramètre fields
sur permissions/permissionDetails
.
Ce champ énumère toutes les autorisations de fichiers héritées et directes pour l'utilisateur, le groupe ou le domaine.
Afficher un exemple
L'exemple de code suivant montre comment déterminer la source du rôle. La réponse renvoie le permissionDetails
d'une ressource permissions
. Le champ inheritedFrom
fournit l'ID de l'élément à partir duquel l'autorisation est héritée.
Requête
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
?fields=permissionDetails&supportsAllDrives=true
Response (Réponse)
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID
",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}
Modifier les autorisations
Pour modifier les autorisations d'un fichier ou d'un dossier, vous pouvez modifier le rôle attribué:
Appelez la méthode
update()
sur la ressourcepermissions
avec le paramètre de cheminpermissionId
défini sur l'autorisation de modification et le paramètre de cheminfileId
défini sur le fichier, le dossier ou le disque partagé associé. Pour trouver lepermissionId
, utilisez la méthodelist()
sur la ressourcepermissions
avec le paramètre de cheminfileId
.Dans la requête, identifiez le nouvel
role
.
Vous pouvez accorder des autorisations sur des fichiers ou des dossiers individuels d'un Drive partagé, même si l'utilisateur ou le groupe en est déjà membre. Par exemple, Alex dispose de role=commenter
en tant que membre d'un Drive partagé. Toutefois, votre application peut accorder à Alex role=writer
pour un fichier dans un Drive partagé. Dans ce cas, comme le nouveau rôle est plus permissif que celui accordé par l'appartenance, la nouvelle autorisation devient le rôle effectif pour le fichier ou le dossier.
Afficher un exemple
L'exemple de code suivant montre comment modifier les autorisations d'un fichier ou d'un dossier de "commentateur" à "rédacteur". La réponse renvoie une instance d'une ressource permissions
.
Requête
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
{ "requests": [ { "role": "writer" } ] }
Response (Réponse)
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "writer"
}
Lister et résoudre les propositions d'accès en attente
Une proposition d'accès est une proposition d'un demandeur à un approbateur d'accorder à un destinataire l'accès à un élément Drive.
Un approbateur peut examiner et traiter toutes les propositions d'accès non résolues pour les fichiers Drive. Vous pouvez ainsi accélérer le processus d'approbation en interrogeant de manière programmatique des propositions d'accès, puis en les résolvant. Il permet également à un approbateur de consulter les propositions de manière globale.
L'API Drive fournit la ressource accessproposals
pour que vous puissiez afficher et résoudre les propositions d'accès en attente. Les méthodes de la ressource accessproposals
fonctionnent sur les fichiers, les dossiers et les fichiers d'un Drive partagé, mais pas sur le Drive partagé.
Les termes suivants sont spécifiques aux propositions d'accès:
- Demandeur: utilisateur qui lance la proposition d'accès à un élément Drive.
- Destinataire: utilisateur qui reçoit les autorisations supplémentaires sur un fichier si la proposition d'accès est accordée. Le destinataire est souvent identique au demandeur, mais ce n'est pas toujours le cas.
- Approbateur: utilisateur chargé d'approuver (ou de refuser) la proposition d'accès. Cela est généralement dû au fait qu'il est propriétaire du document ou qu'il peut le partager.
Répertorier les propositions d'accès en attente
Pour répertorier toutes les propositions d'accès en attente sur un élément Drive, appelez la méthode list()
sur la ressource accessproposals
et incluez le paramètre de chemin fileId
.
Seuls les approbateurs d'un fichier peuvent en afficher les propositions en attente. Un approbateur est un utilisateur disposant de la fonctionnalité can_approve_access_proposals
sur le fichier. Si le demandeur n'est pas un approbateur, une liste vide est renvoyée. Pour en savoir plus sur capabilities
, consultez la section Fonctionnalités.
Le corps de la réponse consiste en un objet AccessProposal
représentant une liste de propositions d'accès non résolues sur le fichier.
L'objet AccessProposal
inclut des informations sur chaque proposition, telles que le demandeur, le destinataire et le message ajouté par le demandeur. Il comprend également un objet AccessProposalRoleAndView
qui regroupe les role
proposés par la personne à l'origine de la demande avec un view
. Étant donné que role
est un champ répété, plusieurs valeurs peuvent exister pour chaque proposition. Par exemple, une proposition peut comporter un objet AccessProposalRoleAndView
de role=reader
et view=published
, ainsi qu'un objet AccessProposalRoleAndView
supplémentaire avec uniquement la valeur role=writer
. Pour en savoir plus, consultez la section Vues.
Transmettez les paramètres de requête suivants pour personnaliser la pagination ou filtrer les propositions d'accès:
pageToken
: jeton de page reçu d'un appel de liste précédent. Fournissez ce jeton pour récupérer la page suivante.pageSize
: nombre maximal de propositions d'accès à renvoyer par page.
Résoudre les propositions d'accès en attente
Pour résoudre toutes les propositions d'accès en attente sur un élément Drive, appelez la méthode resolve()
sur la ressource accessproposals
et incluez les paramètres de chemin d'accès fileId
et proposalId
.
La méthode resolve()
inclut un paramètre de requête action
qui indique l'action à effectuer sur la proposition. L'objet Action
suit le changement d'état de la proposition afin que nous sachions si elle est acceptée ou refusée.
La méthode resolve()
inclut également les paramètres de requête facultatifs role
et view
. Les seuls rôles acceptés sont writer
, commenter
et reader
. Si le rôle n'est pas spécifié, la valeur par défaut est reader
. Un paramètre de requête facultatif supplémentaire de send_notification
vous permet d'envoyer une notification par e-mail au demandeur lorsque la proposition est acceptée ou refusée.
Comme pour la méthode list()
, les utilisateurs qui résolvent la proposition doivent disposer de la fonctionnalité can_approve_access_proposals
sur le fichier. Pour en savoir plus sur capabilities
, consultez la section Fonctionnalités.
Les propositions sont résolues à l'aide des mêmes modèles listés sous Scénarios de partage des ressources Drive. Si plusieurs propositions sont proposées pour un même utilisateur, mais avec des rôles différents, les règles suivantes s'appliquent:
- Si une proposition est acceptée et l'autre refusée, le rôle accepté s'applique à l'élément Drive.
- Si les deux propositions sont acceptées en même temps, la proposition avec l'autorisation la plus élevée (par exemple,
role=writer
par rapport àrole=reader
) est appliquée. L'autre proposition d'accès est supprimée de l'élément.
Une fois une proposition envoyée à la méthode resolve()
, l'action de partage est terminée. Le AccessProposal
n'est plus renvoyé via la méthode list()
. Une fois la proposition acceptée, l'utilisateur doit utiliser la collection permissions
pour mettre à jour les autorisations d'un fichier ou d'un dossier. Pour en savoir plus, consultez la section Modifier les autorisations.
Révoquer l'accès à un fichier ou à un dossier
Pour révoquer l'accès à un fichier ou à un dossier, appelez la méthode delete()
sur la ressource permissions
avec les paramètres de chemin fileId
et permissionId
définis pour supprimer l'autorisation.
Pour les éléments de "Mon Drive", vous pouvez supprimer une autorisation héritée. Supprimer une autorisation héritée révoque l'accès à l'élément et aux éléments enfants, le cas échéant.
Pour les éléments d'un Drive partagé, les autorisations héritées ne peuvent pas être révoquées. Modifiez ou révoquez plutôt l'autorisation sur le fichier ou le dossier parent.
La méthode delete()
permet également de supprimer les autorisations appliquées directement à un fichier ou à un dossier Drive partagé.
Afficher un exemple
L'exemple de code suivant montre comment révoquer l'accès en supprimant un permissionId
. Si la requête aboutit, le corps de la réponse est vide. Pour vérifier que l'autorisation est supprimée, utilisez la méthode list()
sur la ressource permissions
avec le paramètre de chemin fileId
.
Requête
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
Transférer la propriété d'un fichier vers un autre compte Google Workspace de la même organisation
Vous pouvez transférer la propriété des fichiers existants dans "Mon Drive" d'un compte Google Workspace à un autre compte de la même organisation. Une organisation propriétaire d'un Drive partagé est propriétaire des fichiers qu'il contient. Par conséquent, les transferts de propriété ne sont pas acceptés pour les fichiers et dossiers des Drive partagés. Les organisateurs d'un Drive partagé peuvent déplacer des éléments de ce Drive partagé vers leur propre "Mon Drive", ce qui leur transfère la propriété.
Pour transférer la propriété d'un fichier dans "Mon Drive", procédez comme suit:
Créez une autorisation de fichier accordant à un utilisateur spécifique (
type=user
) un accès propriétaire (role=owner
).Mettez à jour l'autorisation d'un fichier existant avec
role=owner
et transférez la propriété à l'utilisateur spécifié (transferOwnership=true
).
Transférer la propriété d'un fichier d'un compte client à un autre
Vous pouvez transférer la propriété de fichiers d'un compte client à un autre. Toutefois, Drive ne transfère pas la propriété d'un fichier entre les deux comptes personnels tant que le propriétaire potentiel n'a pas explicitement donné son consentement au transfert. Pour transférer la propriété d'un fichier d'un compte client à un autre:
Le propriétaire actuel lance un transfert de propriété en créant ou en mettant à jour l'autorisation de fichier du propriétaire potentiel. L'autorisation doit inclure les paramètres suivants:
role=writer
,type=user
etpendingOwner=true
. Si le propriétaire actuel crée une autorisation pour le propriétaire potentiel, une notification par e-mail lui est envoyée pour l'informer qu'il est invité à devenir propriétaire du fichier.Le propriétaire potentiel accepte la demande de transfert de propriété en créant ou en mettant à jour son autorisation de fichier. L'autorisation doit inclure les paramètres
role=owner
ettransferOwnership=true
. Si le propriétaire potentiel crée une autorisation, une notification par e-mail est envoyée à l'ancien propriétaire pour l'informer que la propriété a été transférée.
Lorsqu'un fichier est transféré, le rôle de l'ancien propriétaire est rétrogradé à writer
.
Modifier plusieurs autorisations avec des requêtes par lot
Nous vous recommandons vivement d'utiliser des requêtes groupées pour modifier plusieurs autorisations.
Voici un exemple de modification d'autorisation par lot avec une bibliothèque cliente.
Java
Python
Node.js
PHP
.NET
Articles associés
- Protéger le contenu des fichiers
- Accéder aux fichiers Drive partagés par lien à l'aide de clés de ressources
- Rôles et autorisations