Intermittent authentication failures

[David Kocher]

I am getting intermittent failures with HTTP response code 401 and a response body of

> <?xml version='1.0' encoding='UTF-8'?><Error><Code>AuthenticationRequired</Code><Message>Authentication required.</Message></Error>

This error is not documented at https://developers.google.com/storage/docs/reference-status in the list of HTTP Status and Error Codes.

To my knowledge an authentication header is sent for these requests.

-
David

[Google Storage Team]

Hi David,

Typically, you'll get a 401 if you don't include proper authentication/authorization credentials or if you include an expired OAuth 2.0 access code. The fact that you identified the failure as intermittent leads me to suspect it might be the latter case. If you're using OAuth 2.0, do you have logic to refresh the access token? The standard practice is one or both of the following:

• Keep track of when you obtained the current access token and refresh it any time you find it's older than the life span returned when it was acquired (normally one hour).
• Catch the 401 exception, automatically acquire a new access token and retry the request.

Combining both strategies gives you the best of both worlds because you avoid paying the price of failure recovery most of the time, however, if your time based refresh logic fails for any reason, the recovery strategy provides a backup plan.

Hope that helps,

Marc

Google Cloud Storage Team

[David Kocher]

Marc,

Thanks for the detailed response. We do run OAuth 2.0 authentication with the scenario you describe but only try to expire and refresh the access token if we get a 403 response as this is per the Google Storage documentation. Should we additionally refer to the seperate OAuth 2.0 documentation?

-
David

On 28.02.2012, at 06:29, Google Storage Team wrote:

> Hi David,
>
> Typically, you'll get a 401 if you don't include proper
> authentication/authorization credentials or if you include an expired OAuth
> 2.0 access code. The fact that you identified the failure as intermittent
> leads me to suspect it might be the latter case. If you're using OAuth 2.0,
> do you have logic to refresh the access token? The standard practice is one
> or both of the following:
>

> - Keep track of when you obtained the current access token and refresh

> it any time you find it's older than the life span returned when it was
> acquired (normally one hour).

> - Catch the 401 exception, automatically acquire a new access token and

> retry the request.
>
> Combining both strategies gives you the best of both worlds because you
> avoid paying the price of failure recovery most of the time, however, if
> your time based refresh logic fails for any reason, the recovery strategy
> provides a backup plan.
>
> Hope that helps,
>
> Marc
> Google Cloud Storage Team
>
> On Mon, Feb 27, 2012 at 8:06 AM, David Kocher <dko...@sudo.ch> wrote:
>
>> I am getting intermittent failures with HTTP response code 401 and a
>> response body of
>>
>>> <?xml version='1.0'
>> encoding='UTF-8'?><Error><Code>AuthenticationRequired</Code><Message>Authentication
>> required.</Message></Error>
>>
>> This error is not documented at
>> https://developers.google.com/storage/docs/reference-status in the list
>> of HTTP Status and Error Codes.
>>
>> To my knowledge an authentication header is sent for these requests.
>>
>> -
>> David
>

> --
> You received this message because you are subscribed to the Google Groups "Google Cloud Storage" group.
> To post to this group, send email to gs-dis...@googlegroups.com.
> To unsubscribe from this group, send email to gs-discussio...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/gs-discussion?hl=en.
>

[Google Storage Team]

Hi David,

Sorry for the delayed response. If you attempt to access a bucket or object which you haven't been granted permission to access, you'll receive a "403 Forbidden" response, however, if you specify invalid or stale credentials in the Authorization header, you should receive a "401 Unauthorized" response. So a 401 should trigger your application to refresh its access token.

Hope that helps,

Marc

Google Cloud Storage Team

[David Kocher]

Marc,

Thanks for the detailed clarification. I propose to put that information in the developer documentation. I haven't had any issues since modifying the authentication logic accordingly.

-
David

[mihai]

btw integration with App Engine,  link ( https://developers.google.com/appengine/docs/python/googlestorage is not working) from homepage is not working https://developers.google.com/storage/ .

[Google Storage Team]

David and Mihal,

I just wrote change requests to repair both of the documentation problems you've raised (clarify difference between 401 & 403 responses and fix broken link on Google Cloud Storage home page). 

Glad your authentication logic is working now, David, and thanks to both of you for letting us know about these issues.

Marc

Google Cloud Storage Team

[Google Storage Team]

Hi Roy,

Thanks for the reminder - I see my fix request is still in the assigned state so I just annotated that request with a copy of your email and a request to expedite. Sorry for the delay,

Marc

Google Cloud Storage Team

On Fri, Jun 15, 2012 at 1:29 PM, Roy Hashimoto <roy.ha...@gmail.com> wrote:

Hi -

On Monday, March 5, 2012 7:59:55 AM UTC-8, Google Storage Team wrote:

I just wrote change requests to repair both of the documentation problems you've raised (clarify difference between 401 & 403 responses and fix broken link on Google Cloud Storage home page).

 

There is still no documentation for the 401 status code on:

https://developers.google.com/storage/docs/reference-status

I think it should also be mentioned on:

https://developers.google.com/storage/docs/reference-methods

Each REST command on that page has a section for what status codes can be returned but none of them list 401.

Roy

--
You received this message because you are subscribed to the Google Groups "Google Cloud Storage" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gs-discussion/-/fsNrO6Pdvi4J.