Missing auth headers in response to validate_token

[natefoundry]

I'm encountering what seems to be some sort of edge case with thesign_in and validate_token routes.

In my client app, I am calling the sign_in API, then immediately after calling the validate_token API. What I am noticing is that if the calls happen to close together, the response from validate_token is missing the 'access-token', 'uid', etc.. headers.

However, if I put a break point and wait long enough between the two API calls, the call to validate_token will return the headers in the response with the updated access-token.

Is there some sort edge case here? The calls are happening synchronously as I'm using WEBrick with a single thread, so the API calls are not overlapping.

[nicholasshirley]

I'm using React on the front end and I have observed what seems to be similar behavior, but for all API end points. If requests come too close together the server doesn't send headers, but if I give it about 5 sec in-between requests, it always sends.

Our work around was to just save and send the last headers if no new ones were given. We sometimes can send up to 6 requests with the same headers before getting a new one. config.batch_request_buffer_throttle is turned off in our case, which I would have thought would force new tokens with each request.

[betoharres]

@nicholasshirley it's a known issue, requests made in short periods of time will not respond with credentials, but the last credential still works.

Btw, I'd recommend build your own lib, this one is very buggy and is far from being production ready. For example, go to rails AMS repo and type this repo name and look at the comments.

I also made the mistake from using libraries from @lynndylanhurley, he seems to put a lot of effort but the result was only a buggy authentication. You'd be better building your own library, it's not that hard.

[lynndylanhurley]

it's a known issue, requests made in short periods of time will not responde with credentials, but the last credential it's still working.

@betoharres that's not a bug. the order of the responses can't be guaranteed to the client. so if we include the credentials in every response, then the client may receive the outdated credentials after the last valid credentials.

the only ways to handle it were to either include a timestamp for when each auth token was created, or to not include the token when the request was part of a batch of concurrent requests that all use the same token. the latter option was easier to deal with on both the client and API so we opted for that.

[betoharres]

@lynndylanhurley thanks for the explanation and sorry for my misunderstand about this.
This case could be pointed in the docs since I see so many questions like this

[natefoundry]

The way I'm working around this issue is to just code the handling of the auth headers in the response from validate_token to account for non-existence.