Каждый файл, папка и общий диск 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=owner
.Если для файла для логического значения
writersCanShare
установлено значениеfalse
, у пользователя должно бытьrole=owner
.Если пользователь с
role=writer
имеет временный доступ, ограниченный датой и временем истечения срока действия, он не сможет поделиться файлом. Дополнительную информацию см. в разделе Установка даты истечения срока действия для ограничения доступа к файлам .
Чтобы предоставить общий доступ к папке на «Моем диске», у пользователя должны быть
role=writer
илиrole=owner
.Если логическое значение
writersCanShare
для файла установлено вfalse
, пользователь должен иметь более разрешающуюrole=owner
.Временный доступ (регулируемый датой и временем истечения срока действия) запрещен к папкам "Мой диск" с
role=writer
. Дополнительную информацию см. в разделе Установка даты истечения срока действия для ограничения доступа к файлам .
Чтобы поделиться файлом на общем диске, у пользователя должна быть
role=writer
,role=fileOrganizer
илиrole=organizer
.- Параметр
writersCanShare
не применяется к объектам на общих дисках. Он рассматривается так, как будто для него всегда установлено значениеtrue
.
- Параметр
Чтобы предоставить общий доступ к папке на общем диске, у пользователя должен быть
role=organizer
.- Если для
sharingFoldersRequiresOrganizerPermission
на общем диске установлено значениеfalse
, пользователи сrole=fileOrganizer
могут совместно использовать папки на этом общем диске.
- Если для
Чтобы управлять членством в общем диске, у пользователя должен быть
role=organizer
. Участниками общих дисков могут быть только пользователи и группы.
Установите дату истечения срока действия, чтобы ограничить доступ к файлам
Когда вы работаете с людьми над конфиденциальным проектом, вы можете через некоторое время ограничить им доступ к определенным файлам на Диске. Для файлов в «Моем диске» вы можете установить дату истечения срока действия, чтобы ограничить или удалить доступ к этому файлу.
Чтобы установить дату истечения срока действия:
Используйте метод
create()
для ресурсаpermissions
и установите полеexpirationTime
(вместе с другими обязательными полями). Дополнительные сведения см. в разделе Создание разрешения .Используйте метод
update()
для ресурсаpermissions
и установите полеexpirationTime
(вместе с другими обязательными полями). Дополнительные сведения см. в разделе Изменение разрешений .
Поле expirationTime
указывает, когда истекает срок действия разрешения, используя дату-время RFC 3339 . Срок годности имеет следующие ограничения:
- Их можно установить только для разрешений пользователя и группы.
- Время должно быть в будущем.
- Это время не может быть больше, чем через год.
Дополнительную информацию о сроке действия см. в следующих статьях:
Распространение разрешений
Списки разрешений для папки распространяются вниз, и все дочерние файлы и папки наследуют разрешения от родительского. Всякий раз, когда разрешения или иерархия изменяются, распространение происходит рекурсивно по всем вложенным папкам. Например, если файл существует в папке, а затем эта папка перемещается в другую папку, разрешения для новой папки распространяются на файл. Если новая папка предоставляет пользователю файла новую роль, например «писатель», она переопределяет его старую роль.
И наоборот, если файл наследует role=writer
из папки и перемещается в другую папку, предоставляющую роль «читателя», теперь файл наследует role=reader
.
Унаследованные разрешения нельзя удалить из файла или папки на общем диске. Вместо этого эти разрешения необходимо настроить для прямого или косвенного родительского объекта, от которого они были унаследованы. Унаследованные разрешения можно удалить для элементов в разделах «Мой диск» или «Доступно мне».
И наоборот, унаследованные разрешения могут быть переопределены для файла или папки в «Моем диске». Таким образом, если файл наследует role=writer
из папки «Мой диск», вы можете установить для файла role=reader
чтобы снизить уровень его разрешений.
Возможности
Ресурс permissions
в конечном итоге не определяет способность текущего пользователя выполнять действия с файлом или папкой. Вместо этого ресурс files
содержит набор логических полей capabilities
используемых для указания того, можно ли выполнить действие над файлом или папкой. API Google Диска устанавливает эти поля на основе ресурсов разрешений текущего пользователя, связанных с файлом или папкой.
Например, когда Алекс входит в ваше приложение и пытается поделиться файлом, роль Алекса проверяется на наличие разрешений для файла. Если роль позволяет им делиться файлом, capabilities
связанные с файлом, например canShare
, заполняются относительно роли. Если Алекс хочет поделиться файлом, ваше приложение проверяет capabilities
, чтобы убедиться, что для canShare
установлено значение true
.
Пример получения capabilities
файла см. в разделе Проверка разрешений пользователя .
Создать разрешение
Следующие два поля необходимы при создании разрешения:
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
, чтобы привязать определенный домен к разрешению.
Чтобы создать разрешение:
- Используйте метод
create()
с параметром путиfileId
для связанного файла или папки. - В теле запроса укажите
type
иrole
. - Если
type=user
илиtype=group
, укажитеemailAddress
. Еслиtype=domain
, укажитеdomain
.
Показать пример
В следующем примере кода показано, как создать разрешение. Ответ возвращает экземпляр ресурса Permission
, включая назначенный permissionId
.
Запрос
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
.Создайте разрешение с
type=domain
и задайте для поляdomain
ID .audience.googledomains.com
.
Чтобы просмотреть, как пользователи взаимодействуют с целевыми аудиториями, см. раздел «Взаимодействие с пользователями при обмене ссылками» .
Получите все разрешения для файла, папки или общего диска.
Используйте метод list()
ресурса permissions
, чтобы получить все разрешения для файла, папки или общего диска.
Показать пример
В следующем примере кода показано, как получить все разрешения. Ответ возвращает список разрешений.
Запрос
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"
}
]
}
Проверьте разрешения пользователя
Когда ваше приложение открывает файл, оно должно проверить возможности файла и отобразить пользовательский интерфейс, отражающий разрешения текущего пользователя. Например, если у пользователя нет возможности canComment
для файла, возможность комментирования должна быть отключена в пользовательском интерфейсе.
Дополнительную информацию о capabilities
см. в разделе «Возможности» .
Чтобы проверить возможности, вызовите метод 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, "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 } }
Определите источник роли для файлов и папок на общем диске.
Чтобы изменить роль файла или папки, вы должны знать источник роли. Для общих дисков источником роли может быть членство в общем диске, роль в папке или роль в файле.
Чтобы определить источник роли для общего диска или элементов на этом диске, вызовите метод get()
для ресурса permissions
с параметрами пути fileId
и permissionId
, а для параметра fields
установлено значение поля permissionDetails
.
Чтобы найти permissionId
, используйте метод list()
ресурса permissions
с параметром пути fileId
. Чтобы получить поле permissionDetails
в запросе list
, установите для параметра fields
значение permissions/permissionDetails
.
В этом поле перечислены все унаследованные и прямые права доступа к файлам для пользователя, группы или домена.
Показать пример
В следующем примере кода показано, как определить источник роли. Ответ возвращает сведения permissionDetails
ресурса permissions
. Поле inheritedFrom
предоставляет идентификатор элемента, от которого наследуется разрешение.
Запрос
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
}
]
}
Изменение разрешений
Чтобы изменить права доступа к файлу или папке, вы можете изменить назначенную роль:
Вызовите метод
update()
для ресурсаpermissions
с параметром путиpermissionId
установленным для разрешения на изменение, и параметром путиfileId
установленным для связанного файла, папки или общего диска. Чтобы найтиpermissionId
, используйте методlist()
ресурсаpermissions
с параметром путиfileId
.В запросе укажите новую
role
.
Вы можете предоставить разрешения для отдельных файлов или папок на общем диске, даже если пользователь или группа уже являются его участниками. Например, у Алекса есть role=commenter
как часть его членства на общем диске. Однако ваше приложение может предоставить Alex role=writer
для файла на общем диске. В этом случае, поскольку новая роль является более разрешающей, чем роль, предоставленная посредством их членства, новое разрешение становится эффективной ролью для файла или папки.
Показать пример
В следующем примере кода показано, как изменить права доступа к файлу или папке с комментатора на автора. Ответ возвращает экземпляр ресурса permissions
.
Запрос
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
{ "requests": [ { "role": "writer" } ] }
Ответ
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "writer"
}
Составьте список и примите решение по ожидающим рассмотрения предложениям о доступе
Предложение о доступе – это предложение от запрашивающего к утверждающему лицу предоставить получателю доступ к объекту на Диске.
Утверждающий может просмотреть и принять меры по всем нерешенным предложениям о доступе к файлам на Диске. Это означает, что вы можете ускорить процесс утверждения, программно запросив предложения о доступе и затем разрешив их. Это также позволяет утверждающему лицу просматривать предложения в совокупности.
API Drive предоставляет ресурс accessproposals
, позволяющий просматривать и разрешать ожидающие предложения доступа. Методы ресурса accessproposals
работают с файлами, папками и файлами на общем диске, но не на общем диске.
Следующие условия являются специфическими для предложений доступа:
- Запрашивающая сторона : пользователь, инициирующий предложение доступа к элементу Диска.
- Получатель : пользователь, получающий дополнительные разрешения для файла, если предложение доступа предоставлено. Во многих случаях получатель совпадает с запрашивающим, но не всегда.
- Утверждающий : пользователь, ответственный за утверждение (или отклонение) предложения о доступе. Обычно это происходит потому, что они являются владельцами документа или имеют возможность поделиться им.
Список ожидающих рассмотрения предложений о доступе
Чтобы просмотреть все ожидающие предложения доступа к элементу Диска, вызовите метод list()
ресурса accessproposals
и включите параметр пути fileId
.
Только утверждающие в файле могут перечислять ожидающие рассмотрения предложения в файле. Утверждающий — это пользователь с возможностью can_approve_access_proposals
для файла. Если запрашивающая сторона не является утверждающим, возвращается пустой список. Дополнительную информацию о capabilities
см. в разделе «Возможности» .
Тело ответа состоит из объекта AccessProposal
, представляющего список неразрешенных предложений доступа к файлу.
Объект AccessProposal
включает информацию о каждом предложении, такую как запрашивающая сторона, получатель и сообщение, добавленное запрашивающей стороной. Он также включает объект AccessProposalRoleAndView
, который группирует предлагаемую role
запрашивающей стороны с view
. Поскольку role
— это повторяющееся поле, для каждого предложения может существовать несколько значений. Например, предложение может иметь объект AccessProposalRoleAndView
с значениями role=reader
и view=published
, а также дополнительный объект AccessProposalRoleAndView
только со значением role=writer
. Дополнительную информацию см. в разделе Представления .
Передайте следующие параметры запроса, чтобы настроить нумерацию страниц или отфильтровать предложения доступа:
pageToken
: токен страницы, полученный в результате предыдущего вызова списка. Предоставьте этот токен для получения следующей страницы.pageSize
: максимальное количество предложений доступа, возвращаемых на страницу.
Решите ожидающие предложения о доступе
Чтобы разрешить все ожидающие предложения доступа к элементу Диска, вызовите resolve()
ресурса accessproposals
и включите параметры пути fileId
и proposalId
.
resolve()
включает параметр запроса action
, который обозначает действие, которое необходимо выполнить над предложением. Объект Action
отслеживает изменение состояния предложения, поэтому мы знаем, принимается оно или отклоняется.
resolve()
также включает необязательные параметры запроса role
и view
. Поддерживаются только роли writer
, commenter
и reader
. Если роль не указана, по умолчанию используется reader
. Дополнительный необязательный параметр запроса send_notification
позволяет отправлять уведомление по электронной почте запрашивающей стороне, когда предложение принимается или отклоняется.
Как и в случае с методом list()
, пользователи, разрешающие предложение, должны иметь возможность can_approve_access_proposals
для файла. Дополнительную информацию о capabilities
см. в разделе «Возможности» .
Предложения рассматриваются с использованием тех же шаблонов, которые указаны в разделе «Сценарии совместного использования ресурсов Диска» . Если для одного и того же пользователя имеется несколько предложений, но с разными ролями, применяется следующее:
- Если одно предложение принято, а другое отклонено, принятая роль применяется к элементу на Диске.
- Если оба предложения принимаются одновременно, применяется предложение с более высоким разрешением (например,
role=writer
илиrole=reader
). Другое предложение доступа удаляется из элемента.
После отправки предложения в методsolve resolve()
действие совместного использования завершается. AccessProposal
больше не возвращается через метод list()
. После принятия предложения пользователь должен использовать коллекцию permissions
для обновления разрешений для файла или папки. Дополнительную информацию см. в разделе «Изменить разрешения» .
Отменить доступ к файлу или папке
Чтобы отозвать доступ к файлу или папке, вызовите метод delete()
для ресурса permissions
с параметрами fileId
и пути permissionId
установленными для удаления разрешения.
Для элементов в «Моем диске» можно удалить унаследованное разрешение. Удаление унаследованного разрешения отменяет доступ к элементу и дочерним элементам, если таковые имеются.
Для объектов на общем диске унаследованные разрешения нельзя отозвать. Вместо этого обновите или отмените разрешение для родительского файла или папки.
Метод delete()
также используется для удаления разрешений, непосредственно примененных к файлу или папке на общем диске.
Показать пример
В следующем примере кода показано, как отозвать доступ, удалив permissionId
. В случае успеха тело ответа пустое. Чтобы подтвердить удаление разрешения, используйте метод list()
ресурса permissions
с параметром пути fileId
.
Запрос
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
Передача права собственности на файл другому аккаунту Google Workspace в той же организации.
Право собственности на файлы, существующие в «Моем диске», можно передать из одной учетной записи Google Workspace в другую учетную запись в той же организации. Организация, владеющая общим диском, владеет файлами на нем. Поэтому передача прав собственности не поддерживается для файлов и папок на общих дисках. Организаторы общего диска могут перемещать объекты с этого общего диска на свой собственный «Мой диск», при этом право собственности передается им.
Чтобы передать право собственности на файл в «Моем диске», выполните одно из следующих действий:
Создайте разрешение файла, предоставляющее конкретному пользователю (
type=user
) доступ владельца (role=owner
).Обновите разрешение существующего файла, указав
role=owner
, и передайте право владения указанному пользователю (transferOwnership=true
).
Передача права собственности на файл из одной потребительской учетной записи в другую
Право собственности на файлы может передаваться от одной учетной записи пользователя к другой. Однако Диск не передает право собственности на файл между двумя потребительскими учетными записями до тех пор, пока потенциальный владелец не даст явного согласия на передачу. Чтобы передать право собственности на файл из одной потребительской учетной записи в другую:
Текущий владелец инициирует передачу права собственности, создавая или обновляя права доступа к файлу потенциального владельца. Разрешение должно включать следующие параметры:
role=writer
,type=user
иpendingOwner=true
. Если текущий владелец создает разрешение для потенциального владельца, предполагаемому владельцу отправляется уведомление по электронной почте с указанием, что ему предлагается принять на себя право владения файлом.Потенциальный владелец принимает запрос на передачу права собственности, создавая или обновляя свои права доступа к файлу. Разрешение должно включать следующие параметры:
role=owner
иtransferOwnership=true
. Если потенциальный владелец создает новое разрешение, предыдущему владельцу отправляется уведомление по электронной почте о том, что право собственности было передано.
При передаче файла роль предыдущего владельца понижается до writer
.
Изменение нескольких разрешений с помощью пакетных запросов
Мы настоятельно рекомендуем использовать пакетные запросы для изменения нескольких разрешений.
Ниже приведен пример пакетного изменения разрешений с помощью клиентской библиотеки.
Ява
Питон
Node.js
PHP
.СЕТЬ
Связанные темы
- Защита содержимого файла
- Доступ к файлам на Диске с общим доступом по ссылке с помощью ключей ресурсов
- Роли и разрешения