1

Having a very frustrating issue with Google Drive API.

This is a Google App Engine Java environment.

I need to download a file based on an offline permission - the file is shared ("Can Edit") with the user who gives the offline permission. I am requesting full https://www.googleapis.com/auth/drive scope. I store off the refresh token this generates.

The app then uses this refresh token to get an access token, which it uses to try and download a file. This works file if the file is a Google Apps file (a Google document, spreadsheet etc.) but gives a 401 if the file is an uploaded file with content (e.g. a PDF file, Word file etc.). I can confirm this at a simple level by appending the share urls with ?access_token=xxxx - this works for the Google Apps file but not for an uploaded normal file, which 401's on the webcontentlink url. Note that the https://www.googleapis.com/drive/v2/files/ endpoint responds correctly with the metadata for the uploaded file using the access token that subsequently fails on the download call.

The full html response from either a direct url call (with access_token=) or a servlet call is

<HTML>
<HEAD>
<TITLE>Unauthorized</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Unauthorized</H1>
<H2>Error 401</H2>
</BODY>
</HTML>

Is there a known issue with offline Google auth on non native files in Drive?

Improve this question

1 Answer 1

Reset to default
2

Based on the descriptions of file attributes, you should probably be using the downloadUrl attribute rather than webContentLink.

downloadUrl - Short lived download URL for the file. This is only populated for files with content stored in Drive.

webContentLink - A link for downloading the content of the file in a browser using cookie based authentication. In cases where the content is shared publicly, the content can be downloaded without any credentials.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

I'm beginning to think you are right. It looks like the download url will work with the access token (either with url param or in the header). This isn't ideal for my particular application as I want to store off the url for later retrieval. Assuming the downloadurl really is short lived, I'd have to store off the file id instead and do a call to get a downloadurl and then do the download. I've been around the houses on this so much but I think this is probably the answer - thanks :D
Just for posterity, I was incorrect in saying the downloadurl link would work with an access_token= param, it only works with the authorisation set in the header.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.