I am using the Permissions: get endpoint to check if the user has permission the document.
while i am using this endpoint i came across strange behaviour. it was like this as i need to find out if a given user has permission to edit a given document.
1) if the document directly shared edit permission for that user the above endpoint gives me the correct permission object.
2) if the document is shared with the domain privileges (Anyone at who has the link can edit) . In this case every time it gives me a error response.
My view in this case in the google document view even its the domain level share permission or user level share permission the user get the correct set of workflow. But to check these permission levels from the API endpoints does not works as expected.
Is this a known issue? Is their a another way to check the file permission if it shared under the domain level?
Thanks
Given the fact that there is some missing information (i.e. error message, code snippet, screenshots etc.), I'll make an attempt to answer your question here :)
To check for the file permission, it can be achieved in the following ways:
via Drive API
The Permissions.get resource would be ideal for checking the
permission for a user or domain. You may also try using the
Permissions.list, which would lists all file's permissions.
Google Drive UI
Right click on the file, select "Share..."
Click Advanced
With that being said, I noticed in my testing, if the file (doc) is shared under the domain level and you are not performing this under the same domain, both the view and API resource will return an error response. I suggest making sure when you're calling through the API you're using the appropriate domain user. Hope this helps and Good luck!
The Permissions.Get operation can tell if you a file was shared directly to a user, but it can't tell you if a user has access to the file via a group permission, domain permission, or anyone permission.
Using a Permissions.List operation you might be able to tell if the file is shared to anyone or if it's shared to the user's domain (based on, for example, the user's email address).
Related
After copying a file with a service account, I add a permission of "writer" to a user in the same domain to the copied file and redirect the user to the file's resource "alternateLink".
since a few days ago the user gets the following message "You need permission"
This happens consistently.
refreshing the page grants access to the file.
Is there any way to insure the file is ready for editing by the user before redirecting them? I tried to get the file again with the user's authorization and check it is editable, but that only results in false positives.
Edit: the problem is no longer consistent, I will try suggested answers as if and when it returns.
Your Drive account might take some time to process the calls from the API. With that said, you can rely on the following methods to verify the user's permissions:
You can rely on the "list" function of Drive API, for the Permissions resource.
Within the response from the API, there is the "Items" property, which in turn will show the detailed information about the users for a particular file.
You can find more information in the following reference: https://developers.google.com/drive/v2/reference/permissions/list
If you have access to the user's account, then you could rely on the "Files" resource, using the "get" method for a particular file.
Reference: https://developers.google.com/drive/v2/reference/files/get
One solution that i implemented is setting some safe amount of delay , say 30 seconds using timertask
Participating Components:
(all in the same project)
Android App
Web App
Service Account
The users have authorized the app on their Android devices with Cross Client Identity:
oauth2:server:client_id:[web_app_id].apps.googleusercontent.com scopes ...
Flow:
Several users request the creation of the same file through the Android app ( a file for every user is not desired, see "Known workaround" )
A service account then creates that file ( service account is owner )
Service account shares that file (by link and explicit with users)
User authorized drive service / or service account that impersonates a user tries to copy that file to the user's Google Drive ( User has to be the owner of that copy in the end)
Error:
This fails with scope drive.file ( and also drive.readonly ):
Error Message:
The authenticated user has not granted the app [project_id] write access to the file [file_id]
(btw: why write access is needed with copy()? giving users write access to the file does not change this error)
Known workaround:
It works with full drive scope
( but: my app does not need to see files it has not created - so i want to avoid it)
Same result can also be achieved by re-inserting the file instead of copying it
(this overhead is important for my app though, cause same file might be requested by multiple users)
An explicit interaction with a file from a UI Picker or so will propably not work as the file will have to be created after requesting it. also i can't think of a way how to do that without decreasing usability of the Android app.
Expected result:
www.googleapis.com/auth/drive.file: Per-file access to files created or opened by the app
It seems to me this should be enough.
As the file is created/owned/shared by my app's service account.
and copied by my app on behalf of the user.
www.googleapis.com/auth/drive.readonly Allows read-only access to file metadata and file content
At least this one should work as it should give read access to all files which should be enough to copy a "shared with user" file created by an "authorized by user" app.
Question:
the Web Application and the Service Account are in the same project.
Can the Web Application act like a Service Account on behalf of a user? if so - i don't know how. Would that make a difference anyway?
This seems like a Bug to me in this special use case, as the same result can be achieved with a workaround. At least scope drive.readonly should allow my app to copy app owned files to the user's drive.
Making a copy through the plain Service Account and then changing the owner of that copy to the User would be another workaround, but that fails too.
I must be missing something simple.
Please guide me.
Thank you.
I had the same problem and resolved it using the drive.metadata in combination with the drive.file scopes. Related question
If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).
When creating Google Drive applications there are a number of permission "scopes" that can be specified to indicate to the users what permissions are required to run that application.
One of these permissions:
Perform these operations when I'm not using the application
Causes a lot of concern amongst our users. We could not find any definitive explanation of what causes this permission to be listed.
The only possibility we could think of is that using server-side flow for the OAuth2 means that the server might be still syncronising after the browser has been closed and so this has to be flagged up.
If that's the case, will using JS direct to Drive (no proxy server) mean that this permission will not be requested?
This is due to the OAuth2 flavour you chose.
You probably have taken the web server flow flavour, which build a grant URL with the parameter access_type = offline.
This allows you to obtain a refresh token, so you can access your user's files after he has used your app.
You can replace this access_type paramater to access_type=online but you wont get a refresh token. You will be able to acces your users'files only for one hour. After that, you will have to request a new access token to access his files.
I encourage you to read this page where each of the flow are explained.
The official specifications are a good source of information too.
I have a web app in php mysql, I want to use one google drive account for my app.
Can I use my app's accounts instead of google users for privilages.
I read in SDK I can use service account to login without promting user, but I don't know how to share or give permissions files for custom users.
In api reference I found this:
"The user is not necessarily yet a Google user (e.g. if a file or folder is shared with an email address that does not yet have an associated Google account). Example: 1111459233037698895607".
How a custom user in my app should get a token for own privilages.
I am not exactly sure what you want to achieve here, but if you want to use your own permission system, you can't. You can, however, apply read/write/owner permissions to files to mirror your own permissions.
If I have totally got the wrong idea, please explain.