Review M-Files on G2 & get a $25 gift card Arrow right Review us!

Options
  • Locked Locked
  • Replies 3 replies
  • Subscribers 9 subscribers
  • Views 1205 views
  • Users 0 members are here
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why do cloud vault non-expiration authentication tokens fail after long time?

Victor Vogelpoel
A colleague had an experience with cloud vault authentication tokens that fail after a long time, although NO expiration datetime was submitted when logging on. He proceeded on re-authenticating a REST request in his code whenever a 403 is encountered with the same credentials that was used to authenticate the first time.

Expiring Cloud vault authentication tokens are not a good thing for long running operations.

My question: How do cloud vault authentication tokens expire, although acquired without expiration? What did happen causing the token to invalidate. Things I could think of:
- something changed in the M-Files user account and caused the token to invalidate?
- vault session reset?
- vault server restart?
Parents
  • You are pretty much correct. The authentication token doesn't actually even authenticate the details, which is why you get a token regardless of whether the credentials are correct. It's only upon the actual request for data from the vault is the authentication tried and you get a 403 if it is incorrect. There are a number of reasons as to why the original token - even without an expiry - may become unusable, from the credentials becoming invalid to the cryptographic libraries being updated and the previous token becoming unusable. These possibilities are perhaps even more likely in the cloud due to the transient nature of the cloud hosts.

    I understand your concern about credentials in the HTTP headers, and it would certainly be a last resort for me as well, but if you are executing requests over a HTTPS connection then the details are at least encrypted in transit.

    My recommendation is as per my original message: handle the 403 and re-authenticate. If the token fails after re-authentication then it is possible that something else is problematic (vault offline? credentials incorrect?) and you'll need some exception handling and remediation process.

    Regards,

    Craig.
Reply
  • You are pretty much correct. The authentication token doesn't actually even authenticate the details, which is why you get a token regardless of whether the credentials are correct. It's only upon the actual request for data from the vault is the authentication tried and you get a 403 if it is incorrect. There are a number of reasons as to why the original token - even without an expiry - may become unusable, from the credentials becoming invalid to the cryptographic libraries being updated and the previous token becoming unusable. These possibilities are perhaps even more likely in the cloud due to the transient nature of the cloud hosts.

    I understand your concern about credentials in the HTTP headers, and it would certainly be a last resort for me as well, but if you are executing requests over a HTTPS connection then the details are at least encrypted in transit.

    My recommendation is as per my original message: handle the 403 and re-authenticate. If the token fails after re-authentication then it is possible that something else is problematic (vault offline? credentials incorrect?) and you'll need some exception handling and remediation process.

    Regards,

    Craig.
Children
No Data
M-Files
M-Files Support


© 2024 M-Files, All Rights Reserved.