Skip to content

Set login cookies with a versioned access path#2152

Closed
pcapriotti wants to merge 2 commits intodevelopfrom
pcapriotti/versioned-access
Closed

Set login cookies with a versioned access path#2152
pcapriotti wants to merge 2 commits intodevelopfrom
pcapriotti/versioned-access

Conversation

@pcapriotti
Copy link
Contributor

Checklist

  • The PR Title explains the impact of the change.
  • The PR description provides context as to why the change should occur and what the code contributes to that effect. This could also be a link to a JIRA ticket or a Github issue, if there is one.
  • If HTTP endpoint paths have been added or renamed, the endpoint / config-flag checklist (see Wire-employee only backend wiki page) has been followed.
  • changelog.d contains the following bits of information (details):
    • A file with the changelog entry in one or more suitable sub-sections. The sub-sections are marked by directories inside changelog.d.
    • If public end-points have been changed or added: does nginz need un upgrade?
    • If internal end-points have been added or changed: which services have to be deployed in a specific order?

To pass the API version to HTTP handlers, the version middleware now
sets the `Wire-API-Version` header. The header is not set for API
requests that have no version prefix.
Copy link
Member

@jschaul jschaul left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The lifecycle of the api version evolution on backends and clients is separate from the lifecycle of cookies on a user's device.

Currently, as long as a user uses their device at least once every X (default on wire production = 56 days), they continually refresh their cookies and access tokens and are never prompted for a login.

Say a user's device currently has a cookie with http path /v3/access. Now, a new version of backend and client is released that understands v4 and they both agree to use that. That means the client will make a call to /v4/access but the (existing, valid) cookie won't be sent along, leading to the user getting logged out and having to log in again.

This means users will get logged out each time a new version starts being supported by both clients and backends. That's a serious usability deterioration, in a tradeoff for... what exactly? What do we gain by versioning /access?

@pcapriotti
Copy link
Contributor Author

Abandoned in favour of keeping /access available at its unversioned path.

@pcapriotti pcapriotti closed this Feb 24, 2022
@fisx
Copy link
Contributor

fisx commented Feb 24, 2022

Abandoned in favour of keeping /access available at its unversioned path.

good solution! maybe you can leave a comment in the code somewhere, where future me will find it when he tries the same mistake?

@pcapriotti pcapriotti deleted the pcapriotti/versioned-access branch April 14, 2022 11:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants