Cada archivo, carpeta y unidad compartida de Google Drive tiene recursos permissions
asociados. Cada recurso identifica el permiso para un type
(user
, group
, domain
, anyone
) y role
(owner
, organizer
, fileOrganizer
, writer
, commenter
, reader
) específicos. Por ejemplo, un archivo puede tener un permiso que otorga a un usuario específico (type=user
) acceso de solo lectura (role=reader
), mientras que otro permiso otorga a los miembros de un grupo específico (type=group
) la capacidad de agregar comentarios a un archivo (role=commenter
).
Para obtener una lista completa de los roles y las operaciones que permite cada uno, consulta Roles y permisos.
Situaciones para compartir recursos de Drive
Existen cinco tipos diferentes de situaciones de uso compartido:
Para compartir un archivo en Mi unidad, el usuario debe tener
role=writer
orole=owner
.Si el valor booleano
writersCanShare
se establece enfalse
para el archivo, el usuario debe tenerrole=owner
.Si el usuario con
role=writer
tiene acceso temporal regido por una fecha y hora de vencimiento, no puede compartir el archivo. Para obtener más información, consulta Cómo establecer una fecha de vencimiento para limitar el acceso a los archivos.
Para compartir una carpeta en Mi unidad, el usuario debe tener
role=writer
orole=owner
.Si el valor booleano
writersCanShare
se establece enfalse
para el archivo, el usuario debe tener elrole=owner
más permisivo.No se permite el acceso temporal (que se rige por una fecha y hora de vencimiento) en las carpetas de Mi unidad con
role=writer
. Para obtener más información, consulta Establece una fecha de vencimiento para limitar el acceso a los archivos.
Para compartir un archivo en una unidad compartida, el usuario debe tener
role=writer
,role=fileOrganizer
orole=organizer
.- El parámetro de configuración
writersCanShare
no se aplica a los elementos de las unidades compartidas. Se trata como si siempre estuviera configurado entrue
.
- El parámetro de configuración
Para compartir una carpeta en una unidad compartida, el usuario debe tener
role=organizer
.- Si la restricción
sharingFoldersRequiresOrganizerPermission
en una unidad compartida se establece enfalse
, los usuarios conrole=fileOrganizer
pueden compartir carpetas en esa unidad.
- Si la restricción
Para administrar la membresía de la unidad compartida, el usuario debe tener
role=organizer
. Solo los usuarios y los grupos pueden ser miembros de las unidades compartidas.
Cómo establecer una fecha de vencimiento para limitar el acceso a los archivos
Cuando trabajas con otras personas en un proyecto sensible, es posible que quieras restringir su acceso a ciertos archivos de Drive después de un período determinado. En el caso de los archivos de Mi unidad, puedes establecer una fecha de vencimiento para limitar o quitar el acceso a ellos.
Para establecer la fecha de vencimiento, sigue estos pasos:
Usa el método
create()
en el recursopermissions
y establece el campoexpirationTime
(junto con los otros campos obligatorios). Para obtener más información, consulta Cómo crear un permiso.Usa el método
update()
en el recursopermissions
y establece el campoexpirationTime
(junto con los otros campos obligatorios). Para obtener más información, consulta Cómo cambiar los permisos.
El campo expirationTime
indica cuándo vence el permiso con la fecha y hora de RFC 3339. Los tiempos de vencimiento tienen las siguientes restricciones:
- Solo se pueden configurar en los permisos de usuarios y grupos.
- La hora debe ser posterior a la actual.
- La hora no puede ser superior a un año en el futuro.
Para obtener más información sobre la fecha de vencimiento, consulta los siguientes artículos:
Propagación de permisos
Las listas de permisos de una carpeta se propagan hacia abajo, y todos los archivos y carpetas secundarios heredan los permisos de la carpeta superior. Cada vez que se cambian los permisos o la jerarquía, la propagación se produce de forma recursiva a través de todas las carpetas anidadas. Por ejemplo, si un archivo existe en una carpeta y esta se mueve dentro de otra, los permisos de la carpeta nueva se propagan al archivo. Si la carpeta nueva le otorga al usuario del archivo un rol nuevo, como "escritor", se anula su rol anterior.
Por el contrario, si un archivo hereda role=writer
de una carpeta y se mueve a otra carpeta que proporciona un rol de “lector”, el archivo ahora hereda role=reader
.
No se pueden quitar los permisos heredados de un archivo o una carpeta en una unidad compartida. En su lugar, estos permisos deben ajustarse en el elemento superior directo o indirecto del que se heredaron. Los permisos heredados se pueden quitar de los elementos de "Mi unidad" o "Compartidos conmigo".
Por el contrario, los permisos heredados se pueden anular en un archivo o una carpeta de
Mi unidad. Por lo tanto, si un archivo hereda role=writer
de una carpeta de Mi Drive, puedes establecer role=reader
en el archivo para disminuir su nivel de permiso.
Funciones
En última instancia, el recurso permissions
no determina la capacidad del usuario actual para realizar acciones en un archivo o una carpeta. En su lugar, el recurso files
contiene una recopilación de campos capabilities
booleanos que se usan para indicar si se puede realizar una acción en un archivo o una carpeta. La API de Google Drive establece estos campos según el recurso de permisos del usuario actual asociado con el archivo o la carpeta.
Por ejemplo, cuando Alex accede a tu app e intenta compartir un archivo, se verifica su rol para ver si tiene permisos en el archivo. Si el rol le permite compartir un archivo, los capabilities
relacionados con el archivo, como canShare
, se completan en función del rol. Si Alex quiere compartir el archivo, tu app verifica el capabilities
para asegurarse de que canShare
esté configurado como true
.
Para ver un ejemplo de cómo recuperar el archivo capabilities
, consulta Cómo verificar los permisos del usuario.
Cómo crear un permiso
Los siguientes dos campos son necesarios cuando se crea un permiso:
type
:type
identifica el alcance del permiso (user
,group
,domain
oanyone
). Un permiso contype=user
se aplica a un usuario específico, mientras que un permiso contype=domain
se aplica a todos los usuarios de un dominio específico.role
: El camporole
identifica las operaciones que puede realizartype
. Por ejemplo, un permiso contype=user
yrole=reader
otorga a un usuario específico acceso de solo lectura al archivo o la carpeta. También, un permiso contype=domain
yrole=commenter
permite que todas las personas del dominio agreguen comentarios a un archivo. Para obtener una lista completa de los roles y las operaciones que permite cada uno, consulta Roles y permisos.
Cuando creas un permiso en el que se usa type=user
o type=group
, también debes proporcionar un emailAddress
para vincular el usuario o el grupo específico al permiso.
Cuando creas un permiso en el que type=domain
, también debes proporcionar un domain
para vincular un dominio específico al permiso.
Para crear un permiso, sigue estos pasos:
- Usa el método
create()
con el parámetro de rutafileId
para el archivo o la carpeta asociados. - En el cuerpo de la solicitud, especifica
type
yrole
. - Si es
type=user
otype=group
, proporciona unemailAddress
. Si estype=domain
, proporciona undomain
.
Mostrar un ejemplo
En el siguiente ejemplo de código, se muestra cómo crear un permiso. La respuesta muestra una instancia de un recurso Permission
, incluido el permissionId
asignado.
Solicitud
POST https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
{ "requests": [ { "type": "user", "role": "commenter", "emailAddress": "alex@altostrat.com" } ] }
Respuesta
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "commenter"
}
Cómo utilizar los públicos objetivo
Los usuarios objetivo son grupos de personas, como departamentos o equipos, que puedes recomendar para que los usuarios compartan sus elementos con ellos. Puedes invitar a los usuarios a compartir elementos con un público más limitado o específico en lugar de toda la organización. Los usuarios objetivo pueden ayudarte a mejorar la seguridad y la privacidad de tus datos, y facilitar que los usuarios los compartan de forma adecuada. Para obtener más información, consulta Acerca de los públicos objetivo.
Para usar los públicos objetivo, sigue estos pasos:
En la Consola del administrador de Google, ve a Menú > Directorio > Públicos objetivo.
Para realizar esta tarea, debes acceder con una cuenta que tenga privilegios de administrador avanzado.
En la lista de públicos objetivo, haz clic en el nombre del público objetivo. Para crear un público objetivo, consulta Cómo crear un público objetivo.
Copia el ID único de la URL del público objetivo:
https://admin.google.com/ac/targetaudiences/ID
.Crea un permiso con
type=domain
y establece el campodomain
enID.audience.googledomains.com
.
Para ver cómo interactúan los usuarios con los públicos objetivo, consulta Experiencia del usuario para compartir vínculos.
Cómo recuperar todos los permisos de un archivo, una carpeta o una unidad compartida
Usa el método list()
en el recurso permissions
para recuperar todos los permisos de un archivo, una carpeta o una unidad compartida.
Mostrar un ejemplo
En la siguiente muestra de código, se muestra cómo obtener todos los permisos. La respuesta muestra una lista de permisos.
Solicitud
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
Respuesta
{
"kind": "drive#permissionList",
"permissions": [
{
"id": "PERMISSION_ID
",
"type": "user",
"kind": "drive#permission",
"role": "commenter"
}
]
}
Verifica los permisos de los usuarios
Cuando tu app abre un archivo, debe verificar sus capacidades y renderizar la IU para reflejar los permisos del usuario actual. Por ejemplo, si el usuario no tiene una capability canComment
en el archivo, la capacidad de comentar debe estar inhabilitada en la IU.
Para obtener más información sobre capabilities
, consulta la sección Funciones.
Para verificar las funciones, llama al método get()
en el recurso files
con el parámetro de ruta fileId
y el parámetro fields
configurado en el campo capabilities
. Para obtener más información sobre cómo mostrar campos con el parámetro fields
, consulta Cómo mostrar campos específicos de un archivo.
Mostrar un ejemplo
En la siguiente muestra de código, se muestra cómo verificar los permisos del usuario. La respuesta muestra una lista de las capacidades que el usuario tiene en el archivo. Cada capability corresponde a una acción detallada que puede realizar un usuario. Algunos campos solo se completan para los elementos de las unidades compartidas.
Solicitud
GET https://www.googleapis.com/drive/v3/files/FILE_ID
?fields=capabilities
Respuesta
{ "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 } }
Determina la fuente de roles para los archivos y las carpetas de la unidad compartida
Para cambiar el rol de un archivo o una carpeta, debes conocer la fuente del rol. En el caso de las unidades compartidas, la fuente de un rol puede basarse en la membresía a la unidad compartida, el rol en una carpeta o el rol en un archivo.
Para determinar la fuente de roles de una unidad compartida o los elementos dentro de esa unidad, llama al método get()
en el recurso permissions
con los parámetros de ruta fileId
y permissionId
, y el parámetro fields
configurado en el campo permissionDetails
.
Para encontrar el permissionId
, usa el método list()
en el recurso permissions
con el parámetro de ruta fileId
. Para recuperar el campo permissionDetails
en la solicitud list
, establece el parámetro fields
en permissions/permissionDetails
.
En este campo, se enumeran todos los permisos de archivo heredados y directos del usuario, el grupo o el dominio.
Mostrar un ejemplo
En la siguiente muestra de código, se muestra cómo determinar la fuente del rol. La respuesta muestra el permissionDetails
de un recurso permissions
. El campo inheritedFrom
proporciona el ID del elemento del que se hereda el permiso.
Solicitud
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
?fields=permissionDetails&supportsAllDrives=true
Respuesta
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID
",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}
Cambiar permisos
Para cambiar los permisos de un archivo o carpeta, puedes cambiar el rol asignado:
Llama al método
update()
en el recursopermissions
con el parámetro de ruta de accesopermissionId
establecido en el permiso de cambio y el parámetro de ruta de accesofileId
establecido en el archivo, la carpeta o la unidad compartida asociada. Para encontrar elpermissionId
, usa el métodolist()
en el recursopermissions
con el parámetro de rutafileId
.En la solicitud, identifica el
role
nuevo.
Puedes otorgar permisos a archivos o carpetas individuales en una unidad compartida, incluso si el usuario o el grupo ya es miembro. Por ejemplo, Alex tiene role=commenter
como parte de su membresía a una unidad compartida. Sin embargo, tu app puede otorgarle a Alex role=writer
para un archivo en una unidad compartida. En este caso, como el rol nuevo es más permisivo que el que se otorga a través de la membresía, el permiso nuevo se convierte en el rol efectivo del archivo o la carpeta.
Mostrar un ejemplo
En el siguiente ejemplo de código, se muestra cómo cambiar los permisos de un archivo o una carpeta de comentarista a escritor. La respuesta muestra una instancia de un recurso permissions
.
Solicitud
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
{ "requests": [ { "role": "writer" } ] }
Respuesta
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "writer"
}
Cómo enumerar y resolver las propuestas de acceso pendientes
Una propuesta de acceso es una propuesta de un solicitante a un revisor para otorgarle acceso a un elemento de Drive a un destinatario.
Los revisores pueden revisar y tomar medidas en relación con todas las propuestas de acceso no resueltas en los archivos de Drive. Esto significa que puedes acelerar el proceso de aprobación si consultas de forma programática las propuestas de acceso y, luego, las resuelves. También permite que un revisor vea las propuestas de forma agregada.
La API de Drive proporciona el recurso accessproposals
para que puedas ver y resolver las propuestas de acceso pendientes. Los métodos del recurso accessproposals
funcionan en archivos, carpetas y los archivos dentro de una unidad compartida, pero no en la unidad compartida.
Los siguientes términos son específicos de las propuestas de acceso:
- Solicitante: Es el usuario que inicia la propuesta de acceso a un elemento de Drive.
- Destinatario: Es el usuario que recibe los permisos adicionales en un archivo si se otorga la propuesta de acceso. Muchas veces, el destinatario es el mismo que el solicitante, pero no siempre.
- Aprobador: Es el usuario responsable de aprobar (o rechazar) la propuesta de acceso. Por lo general, esto se debe a que son propietarios del documento o pueden compartirlo.
Cómo ver la lista de propuestas de acceso pendientes
Para enumerar todas las propuestas de acceso pendientes en un elemento de Drive, llama al método list()
en el recurso accessproposals
y, luego, incluye el parámetro de ruta fileId
.
Solo los revisores de un archivo pueden mostrar las propuestas pendientes en un archivo. Un revisor es un usuario con la función can_approve_access_proposals
en el archivo. Si el solicitante no es un revisor, se muestra una lista vacía. Para obtener más información sobre capabilities
, consulta la sección Funciones.
El cuerpo de la respuesta consiste en un objeto AccessProposal
que representa una lista de propuestas de acceso no resueltas en el archivo.
El objeto AccessProposal
incluye información sobre cada propuesta, como el solicitante, el destinatario y el mensaje que agregó el solicitante. También incluye un objeto AccessProposalRoleAndView
que agrupa el role
propuesto por el solicitante con un view
. Dado que role
es un campo repetido, podría haber varios para cada propuesta. Por ejemplo, una propuesta podría tener un objeto AccessProposalRoleAndView
de role=reader
y view=published
, además de un objeto AccessProposalRoleAndView
adicional con solo el valor role=writer
. Para obtener más información, consulta Vistas.
Pasa los siguientes parámetros de consulta para personalizar la paginación de las propuestas de acceso o filtrarlas:
pageToken
: Es un token de página, recibido desde una llamada a lista anterior. Proporciona este token para recuperar la página siguiente.pageSize
: Es la cantidad máxima de propuestas de acceso que se mostrarán por página.
Cómo resolver las propuestas de acceso pendientes
Para resolver todas las propuestas de acceso pendientes en un elemento de Drive, llama al método resolve()
en el recurso accessproposals
y, luego, incluye los parámetros de ruta de acceso fileId
y proposalId
.
El método resolve()
incluye un parámetro de consulta action
que denota la acción que se debe realizar en la propuesta. El objeto Action
realiza un seguimiento del cambio de estado de la propuesta para que sepamos si se acepta o se rechaza.
El método resolve()
también incluye los parámetros de consulta opcionales de role
y view
. Los únicos roles admitidos son writer
, commenter
y reader
. Si no se especifica el rol, el valor predeterminado es reader
. Un parámetro de consulta opcional adicional de send_notification
te permite enviar una notificación por correo electrónico al solicitante cuando se acepte o rechace la propuesta.
Al igual que con el método list()
, los usuarios que resuelven la propuesta deben tener la función can_approve_access_proposals
en el archivo. Para obtener más información sobre capabilities
, consulta la sección Funciones.
Las propuestas se resuelven con los mismos patrones que se indican en Situaciones para compartir recursos de Drive. Si hay varias propuestas para el mismo usuario, pero con roles diferentes, se aplica lo siguiente:
- Si se acepta una propuesta y se rechaza otra, el rol aceptado se aplica al elemento de Drive.
- Si se aceptan ambas propuestas al mismo tiempo, se aplica la propuesta con el permiso más alto (por ejemplo,
role=writer
en comparación conrole=reader
). La otra propuesta de acceso se quita del elemento.
Después de enviar una propuesta al método resolve()
, se completa la acción de uso compartido. El AccessProposal
ya no se muestra a través del método list()
. Una vez que se acepte la propuesta, el usuario deberá usar la colección permissions
para actualizar los permisos de un archivo o una carpeta. Para obtener más información, consulta la sección Cómo cambiar los permisos.
Cómo revocar el acceso a un archivo o una carpeta
Para revocar el acceso a un archivo o una carpeta, llama al método delete()
en el recurso permissions
con los parámetros de ruta de acceso fileId
y permissionId
configurados para borrar el permiso.
En el caso de los elementos de "Mi unidad", es posible borrar un permiso heredado. Si borras un permiso heredado, se revocará el acceso al elemento y a los elementos secundarios, si los hay.
En el caso de los elementos de una unidad compartida, no se pueden revocar los permisos heredados. En su lugar, actualiza o revoca el permiso en el archivo o la carpeta superior.
El método delete()
también se usa para borrar los permisos aplicados directamente a un archivo o una carpeta de Drive compartidos.
Mostrar un ejemplo
En la siguiente muestra de código, se muestra cómo revocar el acceso borrando un permissionId
. Si se ejecuta correctamente, el cuerpo de la respuesta está vacío. Para confirmar que se quitó el permiso, usa el método list()
en el recurso permissions
con el parámetro de ruta fileId
.
Solicitud
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
Cómo transferir la propiedad de un archivo a otra cuenta de Google Workspace en la misma organización
La propiedad de los archivos que existen en "Mi unidad" se puede transferir de una cuenta de Google Workspace a otra cuenta de la misma organización. Una organización que es propietaria de una unidad compartida es propietaria de los archivos que contiene. Por lo tanto, las transferencias de propiedad no son compatibles con los archivos y las carpetas de las unidades compartidas. Los organizadores de una unidad compartida pueden mover elementos de esa unidad a su propia "Mi unidad", lo que les transfiere la propiedad.
Para transferir la propiedad de un archivo en "Mi unidad", haz una de las siguientes acciones:
Crea un permiso de archivo que otorgue acceso de propietario (
role=owner
) a un usuario (type=user
) específico.Actualiza el permiso de un archivo existente con
role=owner
y transfiere la propiedad al usuario especificado (transferOwnership=true
).
Cómo transferir la propiedad de un archivo de una cuenta de consumidor a otra
La propiedad de los archivos se puede transferir de una cuenta de consumidor a otra. Sin embargo, Drive no transfiere la propiedad de un archivo entre las dos cuentas personales hasta que el propietario potencial consienta de forma explícita la transferencia. Para transferir la propiedad de un archivo de una cuenta personal a otra, haz lo siguiente:
El propietario actual inicia una transferencia de propiedad creando o actualizando el permiso de archivo del propietario potencial. El permiso debe incluir esta configuración:
role=writer
,type=user
ypendingOwner=true
. Si el propietario actual crea un permiso para el propietario potencial, se le envía una notificación por correo electrónico en la que se le indica que se le solicita que asuma la propiedad del archivo.El propietario potencial acepta la solicitud de transferencia de propiedad creando o actualizando el permiso de su archivo. El permiso debe incluir estos parámetros de configuración:
role=owner
ytransferOwnership=true
. Si el propietario potencial crea un permiso nuevo, se envía una notificación por correo electrónico al propietario anterior en la que se indica que se transfirió la propiedad.
Cuando se transfiere un archivo, el rol del propietario anterior se cambia a writer
.
Cómo cambiar varios permisos con solicitudes por lotes
Te recomendamos que uses solicitudes por lotes para modificar varios permisos.
El siguiente es un ejemplo de cómo realizar una modificación de permisos por lotes con una biblioteca cliente.
Java
Python
Node.js
PHP
.NET
Temas relacionados
- Protege el contenido de los archivos
- Cómo acceder a archivos de Drive compartidos con vínculos mediante claves de recursos
- Funciones y permisos