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

Prevent New Year POST failures with relative timestamp comparison for Gaia hub token invalidation #171

Closed
jehunter5811 opened this Issue Jan 1, 2019 · 11 comments

Comments

Projects
None yet
5 participants
@jehunter5811
Copy link

jehunter5811 commented Jan 1, 2019

I was in an authenticated sessions when POSTs to Gaia started failing. Per @jcnelson this is because the Gaia hub updated to 2019 and my auth sessions was set to 2018 still.

@jcnelson

This comment has been minimized.

Copy link
Member

jcnelson commented Jan 1, 2019

The Gaia hub uses UTC dates to verify that the auth token is valid for this year. However, it uses the absolute date, so every New Year's Eve we'll see a rolling failure depending on what the user's time zone is. We need to switch the auth payload to include a UNIX timestamp, and verify on the Gaia hub that the current date is no more than 1 year later (or whatever delta we end up using).

@markmhx

This comment has been minimized.

Copy link

markmhx commented Jan 2, 2019

Is it correct then to understand this bug as still invalidating all user sessions established in 2018 as far as Gaia writes are concerned? And all users who want to write to Gaia in 2019 will have to re-authenticate to do so?

@jcnelson if we switch the auth payload, I presume that'd only help new sessions from encountering this going into 2020? Is there any way to hot fix the PBC hub now so that existing sessions aren't essentially broken given the switch into 2019?

@markmhx markmhx added the bug label Jan 2, 2019

@jcnelson

This comment has been minimized.

Copy link
Member

jcnelson commented Jan 2, 2019

Is it correct then to understand this bug as still invalidating all user sessions established in 2018 as far as Gaia writes are concerned? And all users who want to write to Gaia in 2019 will have to re-authenticate to do so?

That is correct.

@jcnelson if we switch the auth payload, I presume that'd only help new sessions from encountering this going into 2020?

Yes, this will happen again in 2020 if we don't fix it.

Is there any way to hot fix the PBC hub now so that existing sessions aren't essentially broken given the switch into 2019?

I'm working on that right now.

@jcnelson

This comment has been minimized.

Copy link
Member

jcnelson commented Jan 2, 2019

#172

@jcnelson

This comment has been minimized.

Copy link
Member

jcnelson commented Jan 2, 2019

Hotfix is now deployed to hub.blockstack.org. Please let us know ASAP if the problem persists.

@jehunter5811

This comment has been minimized.

Copy link

jehunter5811 commented Jan 2, 2019

Verified this fix in Graphite and Stealthy

@markmhx

This comment has been minimized.

Copy link

markmhx commented Jan 3, 2019

@jcnelson Thanks for pushing this hotfix yesterday. I'm assigning this issue to you and changing its title to reflect the remaining token invalidation change needed to prevent this from happening again in a year.

@markmhx markmhx changed the title Happy New Year Bug: If the Gaia Hub has updated to a new year (2019 in this case) but the auth sessions hasn't, posts will fail Prevent New Year POST failures with relative timestamp comparison for Gaia hub token invalidation Jan 3, 2019

@markmhx

This comment has been minimized.

Copy link

markmhx commented Jan 3, 2019

Additionally, can you explain a bit why we have this 1-year invalidation in any case? And even with this fix, won't we find that users who have been authenticated for over a year will encounter POST failures and not realize the reason?

If so, I wonder if there's generally a better way to handle auth token invalidation from a UX perspective.

@kantai

This comment has been minimized.

Copy link
Member

kantai commented Jan 3, 2019

So, two things here.

  1. We don't need to do this timestamping of the auth message at all anymore, since we now support the exp field in the authentication token. Historically, we used this to do rough (very very rough) expiration times on the authentication tokens.

  2. Blockstack.js probably needs to do a better job to try and automatically handle the authentication failures (by, e.g., attempting to reauth) OR we need to add instructions to our documentation and tutorials that tell developers that they should expect to handle auth failures in their code.

@markmhx

This comment has been minimized.

Copy link

markmhx commented Jan 3, 2019

Makes sense. So it sounds as though we should keep this issue open to address the first thing (by removing timestamping entirely) and we should spin up a new issue in a different repo to address the second thing.

Without thinking it through much, my gut tells me that automatically handling reauth, etc. with blockstack.js might be a complicated. And while we may want to evolve to handling failures automatically, we might as well start with better expectation setting in the docs (perhaps with clear guidance on the possible auth failures to expect)?

@moxiegirl moxiegirl added the production label Jan 3, 2019

@markmhx

This comment has been minimized.

Copy link

markmhx commented Jan 4, 2019

@markmhx markmhx closed this Jan 8, 2019

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