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.
Related
Can someone explain Saml2 authentication process? I have installed ckanext-saml2 extension for ckan.I have a extra button in login form which is called login with sso.But I donot have any sp metadata(sp.xml).Also I have idp.xml but what should I write to the this file.Do you have any idea about these files?Should I create a sp.xml file?Also should I change idp.xml file?When I click the button where should I read user information ?
You shouldn't change the idp.xml.
Basically ckanext-saml2 is used to allow Users to enter CKAN portal from other places, rather than only CKAN.
In order to do that, you'll need an idp.xml and sp.xml files.
idp.xml - file that consists of a unique path to the remote Portal where all Users already exists (usually it marked as entityID) and X509 Certificate.
sp.xml - file that is generated by CKAN portal and has pretty much same data as the idp.xml.
Both of those files are used to allow Users to log in into CKAN from other portals. In other words, sp.xml file is provided to the IdP (Identity Provider) and the idp.xml file is provided to the CKAN portal (Service Provider) that is going to use it.
According to the ckanext-saml2 documentation, all configuration should be done in ckanext/saml2/config/sp_config.py file. Configuration should consist entityID URL from idp.xml, path to the idp.xml file, path to logs, data about the CKAN portal, fields that should be taken from the response, their mapping and so on...
After the configuration done, according to documentation, you will be able to generate the sp.xml from the sp_config.py file by using python make_metadata.py sp_config.py.
The button on the login page should redirect you to the IdP login page, where you should log in and be redirected back to CKAN. CKAN will automatically create a User for you if it not exists on the CKAN Portal using the response from the IdP.
For more details, you can check out the Datashades SAML2 CKAN repo or at the original once.
if you are not sure about SSO then you need to have a good reading about that.
Can you tell us what kind of IdP you integrate with? AD FS?
Your sp.xml should be generated by the ckanext-saml2 extension, have a look their git hub page. Then you need to upload sp.xml (sp metadata to your IdP)
I am working on a Onedrive CoAuthoring Application. In which users can Co Author the document and Sync their changes. The application flow is First user initiates the CoAuthoring, the document will moved from Source to Onedrive. For the subsequent users, Permisson will added for those users and they open the document directly from onedrive. so everybody can work on the same document and the final user will sync back it from onedrive to Source.
I have implemented a PoC by creating office 365 trial accounts. I have hard coded the Admin account User credentials, and the admin account will talk to Onedrive on behalf of user using Microsoft Graph and Coauthoring works perfectly.
Now I want to Implement the real version on top of Onedrive Buisness for my organization. My organization using hybrid azure, so that the same onpermise user id is used in Azure too. I have created the application in Azure, created a key(Client secret) and gave necessary permission for the app. i am facing the following issues.
First i tried to pass my onpermise credential, but I am getting invalid password.
Next i tried the code flow, in which i have passed the client id and client secret and got the access token.But when i pass the Access token to the graph api I am getting Code: AccessDenied Message: Either scp or roles claim need to be present in the token.
Next I have created a X509 cert and getting the same error while calling Graph API Code: AccessDenied Message: Either scp or roles claim need to be present in the token.
Need your help/suggestion: I want to talk to onedrive using admin account/app. so that I will move the doc to onedrive and add permission for the subsequent users, and this has to be implemented without user interaction even for the first time. Please help me to overcome the issue.
Thanks,
Subbiah K
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 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.
I have created a bucket in Cloud-Storage, and granted permission for my-gae-app (GAE), as Full_Control. I also configured CORS (Cross-Origin Resource Sharing) on my bucket for my-gae-app. I setup the bucket default ACL to have my-gae-app as owner.
In my-gae-app application, I have form to allow users to upload pdf/image to my-bucket. (I use GCS Client Library Functions) The upload process worked fine, when upload button is clicked, the file is written to my-bucket without error and I can verify from the cloud storage console that the files are there. I checked the files (object) permission, and I can see my-app-gae is the owner.
Other form which display those uploaded files are not working. Even as simple as "<"img src="https://storage.cloud.google.com/mybucket/my-uploaded-image.jpg"/">"
The console show me that "GET ... 403 Forbidden". The page to show the pdf will display "Access Denied Access Denied".
I have tried to mark the object as "Shared Publicly" in the Cloud Storage console, than everything will work fine. But, this is not correct design. I need a solution to make my-bucket access by my-gae-app only, not publicly :o(
Can anyone please shed some light ? Much appreciated.
Whatever "other form which display those uploaded files" is authenticated as needs to be on he access control list for that object with READ or FULL_CONTROL permission. If you want that to be the case for all objects which you create in the bucket, the easiest way to do that is to set a Default Object Access Control for the bucket as described here: https://developers.google.com/storage/docs/accesscontrol#default
With the default object access control set, you can grant READ by default to your form; you just need to find out which user/service account/group your form is authenticating as.