Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

40140 Timestamp not current ideas #76

Open
mattheworiordan opened this issue May 17, 2018 · 5 comments
Open

40140 Timestamp not current ideas #76

mattheworiordan opened this issue May 17, 2018 · 5 comments

Comments

@mattheworiordan
Copy link
Member

mattheworiordan commented May 17, 2018

We often get feedback from customers that they hit timestamp issues, which we do in fact have a support article about, https://support.ably.io/solution/articles/3000068941-40104-timestamp-not-current/

Firstly, this to me is a small as 99% of the time this happens because they are issuing tokens on devices, which they should not be doing. We should be offering

Secondly, if a client receives a 40140, should the client not automatically query server time and try again?

@SimonWoolf @tomczoink @paddybyers WDYT?

┆Issue is synchronized with this Jira Task by Unito

@SimonWoolf
Copy link
Member

We should be offering

...end of this sentence was cut off?

Secondly, if a client receives a 40140, should the client not automatically query server time and try again?

That would help in the case where a lib is issuing a token for itself, but the thing is that is almost always because they're specifying a clientId in the constructor, and that case will be fixed by ably/docs#345

In the case when the issuing server and client are different (and the server time is off) there isn't really much a client can do afaict. Previous discussion ably/docs#142

@mattheworiordan
Copy link
Member Author

We should be offering

...end of this sentence was cut off?

Oops, I meant to say we should include explicit advice in our support articles to consider issuing token requests on their servers, not in their clients.

Secondly, if a client receives a 40140, should the client not automatically query server time and try again?

That would help in the case where a lib is issuing a token for itself, but the thing is that is almost always because they're specifying a clientId in the constructor, and that case will be fixed by ably/docs#345

Sure, but that's not always the case, but I agree this is the most common case now. I agree ably/docs#345 will help reduce the occurrence of this now.

In the case when the issuing server and client are different (and the server time is off) there isn't really much a client can do afaict. Previous discussion ably/docs#142

Sure, but isn't that what queryTime is for?

@SimonWoolf
Copy link
Member

In the case when the issuing server and client are different (and the server time is off) there isn't really much a client can do afaict. Previous discussion ably/docs#142

Sure, but isn't that what queryTime is for?

I'm not really following what you're suggesting the client should do? We don't currently have any mechanism for a client to tell its auth server to use a specific authOption

@mattheworiordan
Copy link
Member Author

I'm not really following what you're suggesting the client should do? We don't currently have any mechanism for a client to tell its auth server to use a specific authOption

Ah, yes, I see what you're saying. So the queryTime option only applies to clients that generate their own tokes...

@QuintinWillison QuintinWillison transferred this issue from ably/docs Oct 3, 2022
@sync-by-unito
Copy link

sync-by-unito bot commented Oct 17, 2022

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-2821

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants