I am trying to download content of a previous revision of a file using the google drive api for Ruby Google::Apis::DriveV3::DriveService#get_revision:
Tempfile.create('file_revision-', encoding: 'ASCII-8BIT') do |temp_file|
drive_api_service.get_revision(file_id, revision_id, download_dest: temp_file)
# work with the content
end
I keep getting Google::Apis::ClientError with status code 403, reason phrase "Forbidden". The scope https://www.googleapis.com/auth/drive is enabled and the error occurs only when I am trying to download the content of the revision. If I run the code without the parameter download_dest, the request succeeds without any problems. I am also able to fetch any meta data or revision, export files, upload files etc., the problem only occurs when I try to fetch the content, either by get_file or get_revision.
Has anyone encountered this issue?
Is there an additional permissions that specifically needs to be added to allow content downloading?
I have also looked at other questions on stack overflow and I have checked all possible configuration for google drive api I could find and everything seems to be enabled.
Right now, Google drive api does not support content downloading for native google drive files (google docs, sheets etc.), so you cant download content (current or of an old revision), you can only export it to a different mime type.
Related
I have a webapp in production that interacts with Google Drive through Google Drive API.
I need to change some settings in Drive interaction but I can't save.
When I save the Drive UI integration page, I receive this error:
There's a problem at our end.
Please try again. If the problem persists, please let us know using
the "Send feedback" link below. Thanks!
(spying Network console: there is an Internal Server Error in a POST call)
I tried to send feedback for months: nobody answers and the bug is still there.
I tried also to create another project: I can save the first time but then the bug returns.
How can I do? Has someone the same problem?
Is there a way to receive a reply from Google? Is there some workaround?
Thank you.
i think that problem must be Client ID
before adding Client ID, go to the Credentials -> OAuth 2.0 Client IDs
then select edit your Client ID. after that your production site url add to Authorized JavaScript origins and Authorized redirect URIs.
then enter your Client ID in Drive UI integration page
For myself trying to get the Drive UI configured I noticed a couple of errors (that don't have any specific error messages)
When adding in an Open URL it has to be a valid domain, so for instance I tried to test it out with local host, to no avail. However something like https://devbox.app.com worked, but something like https://localhost:8888 does not. Even though https://localhost is a valid javascript origin in the client_id configuration (at least for the app I am working on, not sure about other apps), localhost doesn't work as an open URL.
When adding in the mimeTypes it needs to be in the format */* and can include custom mimeTypes like application/custom+xml and application/custom-name+json not sure for other custom types that are not in a particular format like xml or json. Also not sure about wildcards.
When adding in file extensions do not add in the '.' just the name of the file extension.
The app icon I found only failed to upload the image when the image wasn't the exact dimensions, I actually ended up editing some icons in photoshop to change the pixel x pixel values as a quick work around during dev.
That worked for me to get it to save and I tested it with a file that had a custom mimeType (application/custom-name+xml specifically) and custom file extension!
Recently, one of our client reports that he cannot backup files in his Team Drive using our app. We will be thankful if someone can help us figure out why.
We use alt=media method to download file. That is, https://www.googleapis.com/drive/v3/files/[FILE_ID]?alt=media. Reference link here. It works perfectly for most of the files on client side.
However, if we download some of files using this method, we got the following response from Google:
{
"error": {
"code": 500,
"message": null
}
}
These files are in Team Drive and with various extensions (not online doc). For example, .xlsx, .pdf, .jpg, etc. We re-tried few days and ALWAYS got this response message (500 with null message). We cannot get this working even if we append &supportsTeamDrives=true at the end of the URL.
By checking with GET file API, this file DOES exist on Google Drive. Even more surprisingly, we CAN DOWNLOAD this file using the URL provided in downloadUrl field from file resource! How could this happen?
We cannot find more information from Google's API document about this phenomenon. Please help us if someone knows why.
Thank you!
UPDATED:
We got the latest information from our client. It seems that these files are under some folders which are migrated from My Drive to Team Drive. Also, the creation time of these folders are ranging from 2014 to 2016, which are before the official Team Drive early adoption program.
We don't know if these facts are related to the download problem or not, since not all files under these folders are problematic. Only some of these files cannot download through alt=media method.
I am trying to figure out how I can download a large file directly in the browser via the Google Drive API V3.
I'm using option 1 which is : Download a file — files.get with alt=media file resource
When I send my request ( https://www.googleapis.com/drive/v3/files/[fileId]?alt=media), I got the content of the file as a response of it.
Currently I'm creating a blob file with the response of my query, then reading the blob file to start the download on the browser.
The problem with that is, reading the blob file consumes a lot of memory and if the file's size is more than 10MB, then browser crashes.
So my question is : how can I start the download on browsers via the Google APIs like mention on the screenshot bellow? See expected result
Try downloading the file in chunks using the range http header. See https://developers.google.com/drive/v3/web/manage-downloads "Partial download"
I have written a Firefox Extension using Web Extension APIs. It has passed the Preliminary review but the reviewer said that he cannot proceed with the full review cause when he installs it, he gets the following error -
"Unable to parse JSON data for extension storage"
Upon inspecting for quite sometime, I figured that Firefox creates a file called "storage.js" in the profile folder for each extension where it writes and reads from, all the local storage data for that particular extension. And if the extension tries to write to this file before this file is created, the error "Unable to write JSON data to extension storage" is thrown and if the extension code tries to read from this file before this file is created, the error "Unable to parse JSON data for extension storage" is thrown.
Now, my concern is how do I know for sure that the file has been created and that it can be written to or read from?
PS : This happens when the extension is just installed. For consequent sessions, this error wont come as that file is no longer missing.
This seems to be a bug in the current Firefox implementation, and your assessment is spot on:
The underlying ExtStorage module will always call read before get, set etc. even write and clear.
read will unconditionally try to access the underlying, extension specific storage file, that may not exist yet for freshly installed add-ons using the storage API for the first time.
This will therefore result in the logging of one such Unable to parse JSON data for extension storage message, no matter what you do with the storage API.
Therefore triggering the message cannot be avoided.
I suggest you do the following:
Contact the editors team, requesting they re-evaluate your add-on based on:
The message in question is really only a warning (when appearing after first access of the storage API by your addon).
Even when the message would be an actual error (the storage is corrupt), it would still not be your error, as the storage API implementation by mozilla needs to be more resilient then and there is nothing you can do anyway.
The message being issued on first regular use of the storage API, unrelated to what WebExtensions add-on uses that API and in what way, is a mozilla bug, and not something you caused or can fix yourself or at least work around.
Therefore denying a full review just because a mozilla bug erroneously logs a spurious message once without any other severe effects is... questionable.
File a bug about this so mozilla developers can address this issue. You'll wanna CC at least Bill McCloskey (:billm) since he wrote that code ;)
Hi I'M new to windows phone Application development i'm working on how to get access the files from google drive using rest api i got the response in the response i got all the information like .pdf,.docs,mp3,mp4 ,folders etc...and the response is coming slow from the web for that is there any solution that.I should get response only that contains images and folders so that app will fast and accuracy... Thanks in Advance.
https://www.googleapis.com/drive/v2/files?q=mimeType contains 'image/jpeg'
The above link is for getting only images in this way according to mime type we can get the files rather than getting all files at a time