When using token auth with client-side signing, renewing a token is broken

[SimonWoolf]

AFAICT from the log, the issue seems to be that it's sending an authorization: bearer header in the /requestToken request with the old token, which realtime then rejects for outdated auth.

E.g.

(INFO): Auth.requestToken(): using token auth with client-side signing
(INFO): Auth.getTokenRequest(): generated signed request
(VERBOSE): io.ably.lib.http.Http: 
{"keyName":"<redacted>","mac":"UQtfzfHVmsDrs4p4bo0QTbgPVOX0MpS8wcTBypqNq4c=","nonce":"0965490464165070","capability":"","clientId":"<redacted>","timestamp":1505307153354,"ttl":60000}
(VERBOSE): io.ably.lib.http.Http: HTTP request: https://realtime.ably.io:443/keys/<redacted>/requestToken POST
(VERBOSE): io.ably.lib.http.Http:   Authorization: Bearer <redacted>
(VERBOSE): io.ably.lib.http.Http:   Accept: application/json
(VERBOSE): io.ably.lib.http.Http:   Authorization: Bearer <redacted>
(VERBOSE): io.ably.lib.http.Http:   Content-Length: 211
(VERBOSE): io.ably.lib.http.Http:   Content-Type: application/json
(VERBOSE): io.ably.lib.http.Http:   X-Ably-Lib: android-1.0.1
(VERBOSE): io.ably.lib.http.Http:   X-Ably-Version: 1.0
(VERBOSE): io.ably.lib.http.Http: HTTP response:
(VERBOSE): io.ably.lib.http.Http: Access-Control-Allow-Credentials: true
(VERBOSE): io.ably.lib.http.Http: Access-Control-Allow-Origin: *
(VERBOSE): io.ably.lib.http.Http: Access-Control-Expose-Headers: Link,Transfer-Encoding,Content-Length,X-Ably-ErrorCode,X-Ably-ErrorMessage,X-Ably-ServerId,Server
(VERBOSE): io.ably.lib.http.Http: Content-Length: 150
(VERBOSE): io.ably.lib.http.Http: Content-Type: application/json
(VERBOSE): io.ably.lib.http.Http: Date: Wed, 13 Sep 2017 12:52:33 GMT
(VERBOSE): io.ably.lib.http.Http: Vary: Origin
(VERBOSE): io.ably.lib.http.Http: X-Ably-Errorcode: 40142
(VERBOSE): io.ably.lib.http.Http: X-Ably-Errormessage: Token expired
(VERBOSE): io.ably.lib.http.Http: X-Ably-Serverid: frontend.d142.1.eu-west-1-A.i-00a514c8f3a70bd35
(VERBOSE): io.ably.lib.http.Http: X-Android-Received-Millis: 1505307152489
(VERBOSE): io.ably.lib.http.Http: X-Android-Response-Source: NETWORK 401
(VERBOSE): io.ably.lib.http.Http: X-Android-Selected-Protocol: http/1.1
(VERBOSE): io.ably.lib.http.Http: X-Android-Sent-Millis: 1505307152434
(VERBOSE): io.ably.lib.http.Http: 
{
	"error": {
		"statusCode": 401,
		"code": 40142,
		"message": "Token expired",
		"serverId": "frontend.d142.1.eu-west-1-A.i-00a514c8f3a70bd35"
	}
}

[paddybyers]

It's normal for the library to attempt to include credentials in the token request if it has valid credentials; and if it has a token, but doesn't know that the token is expired, then it's expected that this request will be rejected in this way. The library should re-submit the request without the token header. Did you see whether or not this was happening?

[mattheworiordan]

It's normal for the library to attempt to include credentials in the token request if it has valid credentials; and if it has a token, but doesn't know that the token is expired,

But it issued that token so should know.

The library should re-submit the request without the token header. Did you see whether or not this was happening?

It's reusing the same token bearer header each time so not handling the expired failure correctly and trying with a new token.

[SimonWoolf]

The library should re-submit the request without the token header. Did you see whether or not this was happening?

No, it's not -- see eg full log here

It's normal for the library to attempt to include credentials in the token request if it has valid credentials; and if it has a token, but doesn't know that the token is expired...

But it does know that the token has expired. That's why it's getting a new token.

And anyway -- why should it be normal to include (token) credentials in a token request? Only someone with a key should be able to get a token, which means either an unsigned token request done with basic auth, or a signed token request with no auth -- realtime rejects unsigned token requests done with bearer auth anyway, even if the token is valid. (At least, it should. If not then that's a security hole). So at no time does it make sense to send token credentials with a token request, surely

[paddybyers]

So at no time does it make sense to send token credentials with a token request,

Yes, correct. In principle you can have an unsigned token request with basic auth, or a signed token request with no auth. I don't think any libs support the former.