Expired Token doesnt throw an Exception

[kzap]

If you have a long running process like a daemon and it only sets the token upon running the script
after 24 hours the token expires and no error is thrown even if 401s are being returned by the APIs

specifically this was seen in the queuesService->queue->claimMessages but shouldnt it be a global, if a 401 is returned, reauth or throw an Exception rather than silently ignore...

rather than having people to put in logic to look for 401s, by default throw an exception or reauth

here was my debugging log:

# Errors: 0 
# Request:
POST /v1/[CLOUD ID]/queues/[QUEUE NAME]/claims?limit=1 HTTP/1.1
Host: dfw.queues.api.rackspacecloud.com
Content-Type: application/json
User-Agent: OpenCloud/1.14.2 Guzzle/3.9.3 cURL/7.19.7 PHP/5.6.17
Accept: application/json
X-Auth-Token: [OLD TOKEN[
Client-ID: [CLIENT ID]
Content-Length: 24

{"grace":300,"ttl":3600}

# Response:
HTTP/1.1 401 Unauthorized
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 17 Feb 2016 23:27:39 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
WWW-Authenticate: Keystone uri='https://identity.api.rackspacecloud.com/v2.0/tokens'

Authentication required

[PatrickRose]

I hit this and started checking the token's expiration before performing an action. That still led to a few 401's due to the token expiring a second after I checked it but it mostly caught them (the ObjectStore does throw an exception if it was unauthorised).

[kzap]

does that mean each command in the library needs to catch a 401?

what if a 500 is returned, does it throw for any of those errors i wonder? cant find any evidence that it throws for non 2x response codes

I see https://github.com/rackspace/php-opencloud/blob/1ffa26c53ccd737d46b8ec18938bb41e82c37d74/doc/services/object-store/migrating-containers.rst

has an example of using the Guzzle Backoff plugin to retry up to X times depending on certain error response codes, this would be a good idea for rate limits but not for 401s

i would say feature-request

[PatrickRose]

The underlying library (Guzzle) throws exceptions if it gets a 4xx or 5xx response (either a ClientErrorResponse or ServerErrorResponse iirc) where you can get the status.

[jamiehannaford]

@kzap @PatrickRose I think there are two ways to accomplish better reauth handling:

1. Add the following to user code:

   if ($openstack->hasExpired()) {
      $openstack->authenticate();
   }

2. Extend the OpenCloud\OpenStack to either:

   a. Add a request subscriber that checks token validity
   b. Overrides the createRequest method and adds in the validity logic

Because this SDK is entering an EOL cycle and will soon be replaced by the v2 SDK, no major additions will be added, only security fixes. So I recommend sticking with option 1 for the time being. If this issue still persists for the v2 SDK (which I think it does), I'll be more than happy to add this functionality for you.

[kzap]

yes i did the ff:

$token = $client->getTokenObject();

        // If no token exists, or the current token is expired, re-authenticate and save the new token to disk
        if (!$token || ($token && $token->hasExpired())) {
            $client->authenticate();
        }

would like this to be in the next version, i only found out after talking to support that we had been doing millions of 401s :)

[jamiehannaford]

@kzap I've added an issue for you. I'll try to get around to implementing it as soon as I can. I'm assuming you'll be using the Rackspace provider rather than pure OpenStack, right?

[kzap]

Yes rackspace provider
On Feb 22, 2016 9:49 PM, "Jamie Hannaford" notifications@github.com wrote:

@kzap https://github.com/kzap I've added an issue
php-opencloud/openstack#40 for you. I'll try
to get around to implementing it as soon as I can. I'm assuming you'll be
using the Rackspace provider rather than pure OpenStack, right?

—
Reply to this email directly or view it on GitHub
#657 (comment)
.

[kzap]

@jamiehannaford for some reason Guzzle isnt throwing exceptions when it should do at 3.8 even
http://guzzle3.readthedocs.org/http-client/client.html#exceptions

Is exception throwing caught somewhere by openstack or rackspace classes?

[jamiehannaford]

@kzap Which HTTP operation are you expecting to raise an exception?

[kzap]

the 401 when doing a pop() on the cloud queue, i have other libraries which throw an exception when guzzle throws one ,but didnt get one here so i thought there was something preventing that

[jamiehannaford]

@kzap The OpenCloud\Queues\Resource\Queue class doesn't have a pop() method. Would you mind explaining which operation is not throwing an exception when it should?

[kzap]

sorry its claimMessages()

On Fri, Feb 26, 2016 at 6:00 PM, Jamie Hannaford notifications@github.com
wrote:

@kzap https://github.com/kzap The OpenCloud\Queues\Resource\Queue class
doesn't have a pop() method. Would you mind explaining which operation is
not throwing an exception when it should?

—
Reply to this email directly or view it on GitHub
#657 (comment)
.

[jamiehannaford]

@kzap So you're saying that when a 401 occurs during a Queue::claimMessages call, no Guzzle\Http\Exception\ServerErrorResponseException is thrown? If that's the case, how do you know a 401 is being returned?

[kzap]

Yes i was not getting a 401. I knew it qas a 401 only when i run the guzzle
logging plugin and check back after hours and see its getting 401s instead
of 204s
On Feb 26, 2016 11:12 PM, "Jamie Hannaford" notifications@github.com
wrote:

@kzap https://github.com/kzap So you're saying that when a 401 occurs
during a Queue::claimMessages call, no
Guzzle\Http\Exception\ServerErrorResponseException is thrown? If that's
the case, how do you know a 401 is being returned?

—
Reply to this email directly or view it on GitHub
#657 (comment)
.