I have a Google App Engine application that:
Authenticates a user and authorizes the drive.file scope;
Creates and stores a file on behalf of a user via an application-owned 'regular' Google account;
Shares that file with the user (grants write access).
However, when a user attempts to update one of these files via an authorized Drive service created by the app, the following exception is raised:
403: The authenticated user has not granted the app {appId} access to
the file {fileId}.
What am I missing? Given that the file was both initially created by and is still owned by the application, why is it necessary for the user to specifically grant the application access to the file?
My goal is for users to modify files (to which they have write access, that are stored in/owned by an application-owned account) as themselves in order to maintain appropriate 'last modifying user' attribution.
Is there anything I can do to work around this, other than (a) authorizing the 'drive' scope, (b) using the Google Picker or Drive UI to 'explicitly' open files with my app (does this imply the file must live in the user's Drive account?), or (c) having my application-owned account perform all file update operations?
File scope authorization is currently done as a user-app pair. Each user must individually authorize the app to access to the file.
Given that, I think you've identified the possible solutions. For b, the file doesn't need to be owned by the user, they just need access to it. Having shared it with them should be sufficient.
Related
My aim is to be able to call the Google Storage REST APIs with an OAuth token granting an authenticated Google user the read/write permissions on a directory called "directoryName" inside my storage bucket.
So, far I have successfully managed to use the Storage APIs after adding the user to the ACL for the bucket. However, I do not want to grant the user the READ or WRITE permissions on the complete bucket but just on the user's directory inside the bucket e.g. bucket/directoryName.
e.g. I want to be able to call storage.objects.list for a directory inside the bucket without providing the user the permissions for the bucket but just for that directory (and subdirectories).
What I've tried so far: When I tried to call the GET method on https://www.googleapis.com//storage/v1/b/bucket/o?fields=kind%2Citems%28name%29&maxResults=150&prefix=directoryName with the user added to the directory's ACL (as Owner), I get the error response "code":403,"message":"myEmail#gmail.com does not have storage.objects.list access to myBucketName.appspot.com."
Is it possible to provide directory level permissions with Google Cloud Storage and list the contents of that directory only?
As explained in the documentation, there are no such thing as directories in Cloud Storage. As far as Storage is concerned, there are only buckets and inside them objects/files that may or may not have "/" in their name.
Due to this design choice, there's no option to set permissions on a "directory" in Cloud Storage. Please note however that you can create as many buckets as you want for no extra charge. You may create one bucket per user to fit your requirement.
I'm creating an application in with angular and nodejs and I need to be able to read another user's list of events. Right now I am attempting to use "https://graph.microsoft.com/v1.0/users/otherusername#companyurl.com/events" this gives me the 403 "Access is denied. Check credentials and try again.". However, if I use "https://graph.microsoft.com/v1.0/users/myusername#companyurl.com/events" it works(as most would expect). My question is, why is it when I use outlook I can use scheduling assistant to see the events for "otherusername#companyurl.com" without being an admin but in my application I cannot see their events due to credentials?
The library I'm using to connect to microsoft graph api is https://github.com/AzureAD/azure-activedirectory-library-for-js
The delegated permissions I have set in azure are
View users' email address
Sign users in
Read user contacts
Have full access to user calendars
Read user calendars
Send mail as a user
Read directory data
Read all users' basic profiles
Sign in and read user profile
Application permissions (I understand these require admin)
Read calendars in all mailboxes
Graph api permission scopes
Any help is appreciated, thankyou.
Fugal - This is by design. You can use FindMeetingTimes API to schedule meetings with other users. This can be accomplished with just Calendar.Read permission. See http://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_findmeetingtimes for more info.
For you to view another user's calendar using /events endpoint, you need a special permission (something like Calendar.Read.Shared) that we are still in the process of adding. Once we add that, you will be able to use /Events to access any calendar that another user has explicitly shared with you. But if you want to just schedule meetings, FindMeetingTimes should be sufficient.
I hit the below error when trying to insert the permission
"code": 403,
"message": "The authenticated user has not granted the app xxx write access to the child file xxx, which would be affected by the operation on the parent"
Here is what I am doing
We have two Google Account,
1. API Account - we used to create folder and change the ownership to Business account
2. Business Account - upload a file
now we try to share to folder to customer and we hit the above error
And here I using OAuth 2.0 Installed Applications to get the access token.
Please advise what is wrong I am doing here
I had the same issue but I realize that its because of the scope for credential wasn't setup properly. I only had DriveScopes.DRIVE_METADATA set which was not enough for downloading files. Once I added DriveScopes.DRIVE_FILE, DriveScopes.DRIVE, and DriveScopes.DRIVE_APPDATA, I was able to download the file without any problem. Hope this helps.
P.S. if you are changing credentials, you have to delete the previously saved credential file.
Based on the Official Google Documentation you received '403: The user has not granted the app' because the request is not on the ACL for the file. The user never explicitly opened the file with this Drive app.
It is highly recommended to use Google Open Picker and prompt the user to open the file or direct the user to Drive to open the file with the app.
My app uses the Drive rest API and the Drive Realtime API in combination. We set the file's permissions so that the public has view access, and then emailed a link to it to a few thousand customers.
The file's permissions are set so that the public has view access, but:
When a user tries to open the realtime document, we get Drive Realtime API Error: not_found: File not found.
When a user tries to copy the non-realtime file, we get The authenticated user has not granted the app 689742286244 write access to the file 0B-NHh5QARZiUUFctN0Zjc3RKdWs (of course we are not asking to write
You can see the effects for yourself at https://peardeck.com/editor/0B-NHh5QARZiUUFctN0Zjc3RKdWs , and our embarrassing attempts to cover for the errors.
Interesting notes:
Sharing the file directly with a particular google account seems to lift the curse, and then that google account can find the file like normal. No extra permissions, just an explicit reference to a google account.
Setting the file so that the public has full write access seems to have no effect
Other files with the exact same settings in the exact same Drive folder can be opened successfully (but presumably have not been opened by so many people in the past). This makes me think there is some broken state within Google.
How can I avoid this? What's going on?(!?!?) Thanks for any help!
The realtime API does not support anonymous access. All users must have a Google account and be explicitly authorized to view or write to the file.
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.