I've done an experiment by specifying the path to be at my local drive and filled up my own username and password, ended up it hitting exception related to no access right.
Second experiment I've tested by sharing the folder at my local drive to everyone within the domain, and this time filled up using another username that have different SSRS role and it worked smoothly.
The role that I have was Browser and Publisher which should be sufficient. What is exactly mean by Credentials used to access the file share?
Related
I created an image that is uploaded to WDS, with an answer file used for joining the Device to a Domain. Whenever I deploy, a new user is created on the new machine for this Domain user, called DOMAINNAME.Username. I would like to set it up in a way that this Domain user uses the useraccount called Username, which is also on the machine and has all the data of the sysprepped image.
I know it can be done, as I also have images that use the local account that was sysprepped as the domain account of the deployed machine.
Can anyone tell me what step I am missing that leads to what I am experiencing?
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
Is it possible in BusinessObjects 4.0/4.1 to do the following:
Create a report in PDF format
Transfer and store the report on some Windows Share folder
Schedule this process
It this is possible, can anyone give short guidelines on how to do it? Thanks!
Sure, that's basic scheduling functionality.
From Launchpad, right-click on the report and hit "Schedule".
Click the recurrence tab to set the scheduling recurrence.
Click the Formats tab and select Acrobat.
Click the Destinations tab and select File System.
One important note on Destinations -- you can optionally enter the Windows user name and password that will be used to connect to the file share when the report is generated. You can leave this blank, in which case the BO server will connect to the file share as the account that BO runs as (that is, the user name that the SIA service runs as). In this case, the service account must have r/w permission to the file share. On the other hand, if you enter credentials manually, you need to make sure that any recurring schedules get updated if/when you change the accounts password, else the account will quickly get locked out (I know from experience....)
For more info, click the Help menu in Launchpad, then review the section on Scheduling Objects.
My users store some data on my website that they might like to backup on another site, for example dropbox or google docs.
Is there a way for me to save their data into their accounts but (here it comes...) without knowing their password? Like Paypal, where only Paypal sees your password, except more complicated because the user needs to ok that data be copied into their account?
Or does anyone have any clever ideas about this? They could, of course, just copy it to their desktop and drag it in from there. But maybe a nice way to do this??
Or just use the Saver: https://www.dropbox.com/developers/dropins/saver
No auth required. The user just logs in (if not already) and chooses a location, and the file gets saved into their Dropbox.
That is basically what OAuth2 does.
User accesses Google Drive/Dropbox website and log in to grant you access.
Then, you will get special access code which you can use to save data without you knowing user's password.
Here are some links you might find useful:
https://developers.google.com/accounts/docs/OAuth2
https://www.dropbox.com/developers/blog/45/using-oauth-20-with-the-core-api
I am not sure if I am experiencing bugs or if I am doing something wrong. I am developing an app that allows users to create and share a folder on their Google Drive so they can collaborate on the contents of the folder. The folder is created at the root of the user's Google Drive and initially contains a couple of files and one sub-folder with more files.
The first issue is that after inserting a new permission on the main folder, the permission will usually propagate down to all the files and sub-folders, but sometimes it fails to insert the permission on one of the files in the sub directory. Is this feature of propagating permissions to sub-directories something that is officially supported or am i suppose to insert a permission into all the files separately?
The second issue I am experiencing involves the use of the File's userPermission property to check if the role of the current user has changed. It seems that the userPermission property sometimes contains the permission of a recent user and not the current user. The feature I am trying to implement is the ability for a user with whom a folder was shared to check periodically if their permission role has changed. For example has the users permission role changed from "reader" to "writer" or vice-versa. This usually works by listing the folder with the fileId and checking the role property of the userPermission property of the file. However if I am testing this feature with both the user who shares and the user with whom it is shared working within the same client, the get file result will often list the userPermission as the last one to access the file and not the current user. I have tested if this was because I was using the wrong oauth information in the request header but I have ruled this possibility out, the oauth headers are correct for each separate call to get file. I added a test call to about witch lists the users permissionId, just before a call to get file to confirm who the authorized user is. Sill the userPermission with the "me" name appears for the wrong user.
The workaround I have found is to use list files which returns the file in the list with the correct userPermission.
In the reference located at https://developers.google.com/drive/v2/reference/files#resource for the description of the userPermission property is "The permissions for the authenticated user on this file."
I am wrong to interpret this to mean the userPermission will always show the role of the current user? And if it is showing the wrong permission, what could be the cause??
userPermission and me represents the current authenticated user, if it's showing the wrong permission you're authenticating the user with the wrong token.
the permission will usually propagate down to all the files and sub-folders
This case may not be true for sub folders and files with their own explicit permissions.
With regard to the first problem, which was that after sharing a folder, only one of its contents would consistently not get shared, I have discovered the cause. The file that was not getting shared is actually a Fusion Tables file and in my script, immediately after inserting the permission, a call is made to insert a new row into the Fusion table file which seems to prevent the permission from being added to that file at that time, or ever. So the workaround I found is to wait a couple of seconds after making the insert permission call, then check that the permission is already in place using a list permission call before calling the Fusion Tables query.
Now with regard to the second problem, this is probably a bug of some sort since I confirmed that I am using the correct oauth token, and by the fact that the workaround I have found works, which is to use a call to list file instead of get file. The only difference is that the file name or other query parameter is required to make the call in addition to the file id. In my case the file object returned with the list file will always contain the correct values in the userPermission field whereas with get file, the userPermission will sometimes contain information for an other user.