Getting 401 Unauthorized error on a doc where the user is owner.

6,952 views
Skip to first unread message

Robert Kaufman

unread,
Mar 30, 2012, 10:53:22 AM3/30/12
to google-docum...@googlegroups.com
Hello,

I am getting a 401 Unauthorized error when trying to download a certain doc for a user. I can't post the information publicly, but in the ACLs, the user is listed as the owner. In addition, in the past I was able to download the doc, and the ACL at that time was the same as it is now. But as of a few days ago, I am getting back a 401 Unauthorized message instead. What could cause this to happen?

Thanks,
Rob

Claudio Cherubino

unread,
Mar 30, 2012, 12:49:16 PM3/30/12
to google-docum...@googlegroups.com
Hi Rob,

Does your request include the Authorization header with a valid token?
Are you using one of the client libraries or manually constructing the request?
Thanks

Claudio

dillan

unread,
Mar 30, 2012, 1:51:40 PM3/30/12
to Google Documents List API
I too am getting this behavior on my google docs account. I have a
single document that shows my account as being a writer in the
documents ACL.The request is submitted with a valid auth token using
the Objective-C API.

Thanks for your help!

- Dillan

On Mar 30, 11:49 am, Claudio Cherubino <ccherub...@google.com> wrote:
> Hi Rob,
>
> Does your request include the Authorization header with a valid token?
> Are you using one of the client libraries or manually constructing the
> request?
> Thanks
>
> Claudio
>

Robert Kaufman

unread,
Mar 30, 2012, 3:48:26 PM3/30/12
to google-docum...@googlegroups.com
Hi Claudio,

Yes, the request includes the Authorization header with a valid token. I am able to download other docs for the same user without a problem. I am using the Ruby OAuth gem.

Thanks,
Rob

Claudio Cherubino

unread,
Mar 30, 2012, 6:42:46 PM3/30/12
to google-docum...@googlegroups.com
Hi Rob,

Do you think it is possible to reproduce this with another document so that we can perform some tests?
At the moment we only know that this happens with a single document and a single user, but without either of them it is hard for us to understand what's going on.
Thanks

Claudio

Robert Kaufman

unread,
Apr 2, 2012, 8:38:52 AM4/2/12
to google-docum...@googlegroups.com
Hi Claudio,

I have seen this error happen with several users, with several documents for each. I realize now that my original post implied otherwise, but I was just trying to specify that while most documents for the user had no problems, some of them did. Can I email you a list of a few sample docs where the problem is occurring?

Thanks,
Rob

Claudio Cherubino

unread,
Apr 2, 2012, 1:59:42 PM4/2/12
to google-docum...@googlegroups.com
Hi Rob,

Sure, please send me those docs.
Thanks

Claudio

Kouji Takano

unread,
Apr 3, 2012, 7:53:13 AM4/3/12
to google-docum...@googlegroups.com
Hi Claudio,

We too have the same problem, getting 401 error exporting documents from Google Docs.

We use OAuth2 for authorization and the change of the OAuth2 scope setting on the server side seems to be the cause.
As an experiment, we changed the scope for our app from http://docs.google.com/feeds/ to https://docs.google.com/feeds/ and executed authorization again. The error has vanished after that.

Our app has sync feature with Google Docs, listing-up and uploading documents works fine with non-ssl scoped OAuth2. Only exporting is affected.

|Are you using one of the client libraries or manually constructing the request?

We manually construct the request.
We also use GTM-OAuth2 module for authentication.

Thank you for your time.
Kouji


2012年3月31日土曜日1時49分16秒 UTC+9 Claudio Cherubino:

Claudio Cherubino

unread,
Apr 3, 2012, 1:19:21 PM4/3/12
to google-docum...@googlegroups.com
Hi Kouji,

If you were using a token with an old or invalid scope that would explain the 401 errors.
The http scope is definitely the wrong one and it shouldn't work at all, perhaps it is still supported for backward compatibility, but it is not documented anymore and it can be dropped anytime, so please make sure you only use the https scope.

Robert, can you confirm you are only using the scopes listed in the documentation?


Claudio

Robert Kaufman

unread,
Apr 3, 2012, 2:20:18 PM4/3/12
to google-docum...@googlegroups.com
Hi Claudio,

Yes, I am only using the scopes listed in the documentation you linked.

Rob

Terence Pua

unread,
Apr 3, 2012, 11:23:56 PM4/3/12
to google-docum...@googlegroups.com
Hello Claudio,

Ditto here. Any ETA on the fix?

Thanks,
Terence

Kouji Takano

unread,
Apr 4, 2012, 12:22:19 AM4/4/12
to Google Documents List API
Hi Claudio,

We can change the scope easily, and we will do it.

However, our customers have to wait til Apple approve the new version
(our app is for iPhone).
Couldn't you change the server settings back and accept http scope
again to help them?
In the past 30 hours, we suddenly started receiving many letters
claiming about unauthorized error on syncing.

|The http scope is definitely the wrong one and it shouldn't work at
all,

You are right if we are developing a new application for Google Docs.

However, we have been provided the sync feature for over 2 years in
our app, and we implemented OAuth2 authentication 5 months ago.
We use API v2 for export, which is not deprecated.
In the documentation of v2, the scope for OAuth is http(s)://
docs.google.com/feeds/ like written in http://code.google.com/intl/en/apis/gdata/faq.html
.

Please reconsider of accepting http scope for exporting KIX documents.
FYI, old Writely documents keep compatibility and accept http scope
for any access.

Kouji

On 4月4日, 午前2:19, Claudio Cherubino <ccherub...@google.com> wrote:
> Hi Kouji,
>
> If you were using a token with an old or invalid scope that would explain
> the 401 errors.
> The http scope is definitely the wrong one and it shouldn't work at all,
> perhaps it is still supported for backward compatibility, but it is not
> documented anymore and it can be dropped anytime, so please make sure you
> only use the https scope.
>
> Robert, can you confirm you are only using the scopes listed in the
> documentation?
>
> https://developers.google.com/google-apps/documents-list/#authorizing...
> *
> *

Claudio Cherubino

unread,
Apr 4, 2012, 12:50:06 PM4/4/12
to google-docum...@googlegroups.com
Hi Kouji,

I can't change the server settings back to accept http scope as this is part of a big effort at Google to improve security by requiring SSL only for our APIs.
For instance, in September 2011 we publicly announced we started requiring SSL to make requests to the Documents List API, the Spreadsheets API and the Sites API:


The table at http://code.google.com/intl/en/apis/gdata/faq.html specifically lists OAuth 1.0 scopes while for OAuth 2.0 it invites to check the API-specific documentation. 

Claudio

Marte

unread,
Apr 5, 2012, 2:38:05 AM4/5/12
to google-docum...@googlegroups.com
Hi Claudio, we're also experiencing it even though we're using https scopes. What we notice is that only exporting of native document to doc format is problematic, and downloading / exporting of other files (including arbitrary files) works. We've narrowed it down to using a scope without a trailing slash (i.e. "https://docs.google.com/feeds" instead of "https://docs.google.com/feeds/").

Rob, can you confirm if your issue is the same as ours?

We're going to change our end to use the one with trailing slash, but can you do something to accommodate this scope? We have a lot of users using this scope already and it'll be a pain if we have them re-authorize as it has always been working before. In the authorization page for the user, both strings are working and have the same set of permissions being asked from them.

Additionally, exporting of spreadsheets still works even though our scope also missed a trailing slash ("https://spreadsheets.google.com/feeds" instead of "https://spreadsheets.google.com/feeds/") and we're requesting to keep it working. The scope for contacts API ("https://www.google.com/m8/feeds") is intended to have no trailing slash but it also works either way (in our case we have this right but I can see code in the open that uses the one with a trailing slash).

Thank you for your time.

Kouji Takano

unread,
Apr 5, 2012, 6:52:59 AM4/5/12
to Google Documents List API
Hi Claudio,

Security is important and the change itself is a good thing.

|http://googleappsdeveloper.blogspot.com/2011/09/requiring-ssl-for-
documents-list.html

We have read the article. We also knew there is a similar post on
Google Code Blog 03/2011 in advance.
However, as API v2 document says both http and https are okay even on
11/2011, I made a mistake on interpreting it.

Thanks for your detailed reply and sorry for asking you difficult
thing.

Kouji

On 4月5日, 午前1:50, Claudio Cherubino <ccherub...@google.com> wrote:
> Hi Kouji,
>
> I can't change the server settings back to accept http scope as this is
> part of a big effort at Google to improve security by requiring SSL only
> for our APIs.
> For instance, in September 2011 we publicly announced we started requiring
> SSL to make requests to the Documents List API, the Spreadsheets API and
> the Sites API:
>
> http://googleappsdeveloper.blogspot.com/2011/09/requiring-ssl-for-doc...
>
> The table athttp://code.google.com/intl/en/apis/gdata/faq.htmlspecifically
> lists OAuth 1.0 scopes while for OAuth 2.0 it invites to check
> the API-specific documentation.
> The Docs List API documentation (https://developers.google.com/google-apps/documents-list/#authorizing...)

Robert Kaufman

unread,
Apr 5, 2012, 1:01:13 PM4/5/12
to google-docum...@googlegroups.com
Hi Marte,

Indeed, we are missing the trailing slash on the
"https://docs.google.com/feeds/" scope. I will make that change, and
see if it fixes our problem, though like you said, it will be a pain
to reauthorize all of our existing users.

Rob

Robert Kaufman

unread,
Apr 9, 2012, 9:43:29 AM4/9/12
to google-docum...@googlegroups.com
Hi All,

I made the change suggested by Marte, to add a trailing slash to the scope, and it fixed our problem.

I will plan on making existing users reauthorize, but it would be really nice if Google would fix this bug instead (assuming it is considered a bug).

Thanks,
Rob
Reply all
Reply to author
Forward
0 new messages