Why does the webContentLink access I get through the http interface of the Google cloud disk list report 404 - google-drive-api

I obtained the file download url through the following interface, and the corresponding field is webContentLink, but why did I return a 404 status code when I accessed this download url. I have tested this problem only with some of these accounts. There is no idea to solve this problem now.
interface address:https://developers.google.com/drive/api/v3/reference/files/list?hl=en&authuser=1

According to their docs, WebContentLink is only available for files with binary content in Google Drive.
If you want to download all kind of file then use the files.get method with the ID of the file to download and set the alt=media URL parameter
Reference: https://developers.google.com/drive/api/guides/manage-downloads#download_a_file_stored_on_google_drive

Related

Google Drive API no longer working to list files in folder

I have some Perl code that retrieves a list of files from a specified folder on my Google drive using the following GET URL:
https://www.googleapis.com/drive/v3/files?q='[FOLDER_ID]'+in+parents&fields=files(name,webViewLink,thumbnailLink,videoMediaMetadata/durationMillis)&key=[GOOGLE_DRIVE_API_KEY]
I have not changed anything recently, but today I noticed that the using this URL returns an empty files array. The response code is "200" and the content body of the response is:
{
"files": []
}
I have validated that the folder ID is still correct according to Google Drive.
I have validated that my Google Drive API key is still enabled and correct.
I have validated that the files do exist in that folder on the Google Drive.
Has something changed on the Google API side that would cause this API request to stop returning the list of files in the specified folder?
Thanks!
Finally figured this out: I needed to pass the
X-Goog-Drive-Resource-Keys
HTTP header with the request, and set its value to:
[FOLDER_ID]/[FOLDER_RESOURCE_KEY]
Apparently, as part of Google's Drive API security update this month, links that are shared for "everyone with the link" now require this HTTP header and the resource ID/key to access those shared files.

Get 404 error when accessing a public file's meta data on Google Drive

I have a file which is shared public.
https://drive.google.com/file/d/1SuYrjwWJKlNmSEr6CpcOVFUT1MpGqLe3/view
But when I use Google API to access the file's meta data, the result is 404 not found.
https://www.googleapis.com/drive/v3/files/1SuYrjwWJKlNmSEr6CpcOVFUT1MpGqLe3
Can someone tell me the reason of this behavior?
If you want to access via Drive API a file that is not located on your Drive, you need to set
supportsAllDrives to true:
https://developers.google.com/drive/api/v3/reference/files/get?apix_params=%7B%22fileId%22%3A%221SuYrjwWJKlNmSEr6CpcOVFUT1MpGqLe3%22%2C%22supportsAllDrives%22%3Atrue%7D

Does current Google Drive Api give option similar to downloadUrl with access token in query string?

Before January 1, 2020 Google Drive API allows to specify access token in query string. Therefore it was possible to get downloadUrl for video file in Google Drive, then to add access token as parameter in the query string and this url can be used as source url for html player in browser. Now in accordance with changes to the Google Drive API this way does not work. The article recommends to use webContentLink but it seems they require cookies. Therefore if user is not logged into corresponding Google account the webContentLink cannot be used as source url for html player as instead of content of the file it returns Google page for login. If I share the file then webContentLink returns the file content but this variant is not acceptable for me. I know that it is possible to download file in browser memory and then to use data url. But this variant is not good for big video file as before playing all file has to be download.
Does Google Drive API offer at current moment an option similar to downloadUrl with access token in query string?

Can download files (without file name or extension), but unable to see them?

I'm using the Google Drive API to generate a downloadable link for a file that looks like this:
https://www.googleapis.com/drive/v3/files/{file_id}?access_token={access_token}&alt=media
The problem is files are being downloaded without name and without extension.
If I add the extension manually after the file downloads it still works, but it's bad to tell my users they have to do that every time, and the user would have to know which extension the file actually has.
If I call https://www.googleapis.com/drive/v3/files/?access_token={access_token}
I can't see the files I've uploaded... I think it could be a problem related to having access to the files' metadata, but I did authorize the auth.files.metadata scope.
I generate the access token using the refresh token and obtained the refresh token from the Oauth Playground... I'm confident I used the proper credentials for my application, but I could triple-check if someone suggests this could be the problem.
What can I do to debug this?

When/why can file.downloadUrl be empty for a PDF file selected from Google Drive?

Using js file picker to select PDF files from Google Drive.
I'm encountering an instance when the downloadUrl is undefined.
I don't understand what can cause this.
I know downloadUrl can be empty for native Google formats, but these are PDF files.
I'd like to know what scenarios (except native Google formats) can cause an empty downloadUrl.
Thanks
You should use the Drive API to fetch the picked files' metadata in order to retrieve the downloadUrl. https://developers.google.com/drive/v2/reference/files/get
Native Google formats can be downloaded (converted and downloaded) via their exportLinks: https://developers.google.com/drive/v2/reference/files#exportLinks
The response I was receiving was 403.
And the scenario was user accessing "work" Drive (Google Drive for your domain)
Turns out Google Drive for your domain Administrators can restrict the permission to install third party apps.
https://support.google.com/a/answer/6105699?hl=en
User will still be able to allow access for the app and select files. Its just going to fail every time with a 403. Very confusing UX.