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

Session renewal failure #209

Closed
ricellis opened this issue Mar 15, 2021 · 1 comment · Fixed by #340
Closed

Session renewal failure #209

ricellis opened this issue Mar 15, 2021 · 1 comment · Fixed by #340
Assignees

Comments

@ricellis
Copy link
Member

Describe the bug

Session renewal does not complete successfully. It is not yet clear whether this is always the case or intermittent.

To Reproduce

Discovered during E2E testing where the client was running for longer than the session cookie lifetime.

  • Create client using COUCHDB_SESSION auth
  • Receive cookie with 1 minute lifetime
  • Do stuff for > 1 minute
  • Do more stuff, but receive 401 responses because cookie is expired

Relevant logs:

  1. Initial cookie obtained from server
    [2021-03-15T06:36:42.614Z] �[33mgauge-sdks_1      |�[0m �[0m�[0;32m          * Create client	 ...[PASS]
    [2021-03-15T06:36:42.614Z] �[36mcloudant-image_1  |�[0m [notice] 2021-03-15T06:36:41.935912Z couchdb@127.0.0.1 <0.619.0> 59a573ee5e cloudant-image:5984 172.19.0.3 undefined POST /_session 200 ok 10
    
  2. After 80% of cookie lifetime (48 seconds) a successful _session request is made for a new cookie
    [2021-03-15T06:37:29.745Z] �[36mcloudant-image_1  |�[0m [notice] 2021-03-15T06:37:29.295427Z couchdb@127.0.0.1 <0.4494.0> 7f4b33d72c cloudant-image:5984 172.19.0.3 admin POST /_session 200 ok 3
    
  3. One minute after the original cookie request 401 failures are observed
    [2021-03-15T06:37:42.210Z] �[36mcloudant-image_1  |�[0m [notice] 2021-03-15T06:37:42.104932Z couchdb@127.0.0.1 <0.5828.0> 95f42bfa19 cloudant-image:5984 172.19.0.3 undefined PUT /gauge-e4cf959e-75ed-4e12-be6e-16ec73a6c2e8?partitioned=false 401 ok 1
    

Expected behavior

The renewal process should replace the old cookie with a new one, but although a new cookie is obtained it appears to not be correctly applied to later requests.

Screenshots

Must gather (please complete the following information):

  • SDK Version [e.g. 1.2.1] 0.0.14 (+dev)
  • Node.js Version [e.g. Node.js 14.15.1] 10.24.0
  • Name of service that you're trying to use (if applicable)
  • Name of operation that you're trying to invoke (if applicable)

Additional context

ibm-cloud-sdk-core@2.8.2
Since the request to renew the session was made and was successfully answered by the server it seems like either the new cookie is not saved correctly into the cookie jar or the value from the cookie jar is not applied to requests.

@emlaver emlaver self-assigned this Mar 26, 2021
@ricellis
Copy link
Member Author

ricellis commented Apr 14, 2021

@emlaver and I have been debugging this and I'm now confident that the problem is that tough-cookie purges the renewed cookie from the jar at the expiry time of the original cookie. This leaves the session token manager and the cookie jar out of sync.

The reason that tough-cookie removes the renewed cookie is a little complicated.

Firstly, RFC 6265 says

If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie.

Since CouchDB sends cookies with both Expires and Max-Age the Max-Age is the one that gets used by tough-cookie.

Secondly, RFC 6265 5.3.11.3 is quite clear that the creation time of the cookie should be preserved on update

   3.  Update the creation-time of the newly created cookie to match the creation-time of the old-cookie.

This means that the creation time of the cookie after the session renewal update remains the original session creation time.

The spec is unclear on whether a Max-Age based expiry time should be updated when a cookie is updated. It appears that the behaviour of many browsers is that the Max-Age is related to the storage time of the cookie (thus sliding the expiry when a cookie is updated). However, the tough-cookie interpretation is that it is related to the creation time of the cookie (which we've seen always remains the original cookie creation time). See salesforce/tough-cookie#154 - it seems unlikely that tough-cookie will change default behaviour, but there may be scope for an option to change it.

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 a pull request may close this issue.

2 participants