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

Options
  • Locked Locked
  • Replies 3 replies
  • Subscribers 9 subscribers
  • Views 1204 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
  • Hello Craig,

    Thank you for your clarification. I'll take care of the re-authenticating.

    The authentication token is returned when logging on with credentials (and some other information). In my mind, certain authentication actions have already taken place and makes using a token 'more efficient' than specifying username and password (X-Username, etc.) in the header of each request.

    But the page also states:
    The M-Files Web Service will return an authentication token regardless of whether authentication was successful or not.


    Is the login procedure no more than a valid user/vaultId check and returning the authentication details object as an encrypted (JWT?) token, and the credentials are not even verified?
    The M-Files server would decrypt the token and authenticate/authorize each request using the decoded authentication details?

    Still, I'd rather not specify user credentials in plain text in the headers of each request...

Reply
  • Hello Craig,

    Thank you for your clarification. I'll take care of the re-authenticating.

    The authentication token is returned when logging on with credentials (and some other information). In my mind, certain authentication actions have already taken place and makes using a token 'more efficient' than specifying username and password (X-Username, etc.) in the header of each request.

    But the page also states:
    The M-Files Web Service will return an authentication token regardless of whether authentication was successful or not.


    Is the login procedure no more than a valid user/vaultId check and returning the authentication details object as an encrypted (JWT?) token, and the credentials are not even verified?
    The M-Files server would decrypt the token and authenticate/authorize each request using the decoded authentication details?

    Still, I'd rather not specify user credentials in plain text in the headers of each request...

Children
No Data
M-Files
M-Files Support


© 2024 M-Files, All Rights Reserved.