mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Error decoding JWT when ExpiredSignature #1374
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tessus on GitHub (Oct 4, 2022).
Subject of the issue
I have invited a user via the admin panel about 10 days ago (
SIGNUPS_ALLOWED=false,SIGNUPS_VERIFY=false). Today the user tried to register, but got the following error after clickingSubmit:Error decoding JWT.I suspected that the invitation was expired and checked the log file:
Then I have noticed that I can't just resend an invitation. There's no resend option in the admin panel, nor can I re-invite the user. (user already exists error message)
I had to delete the user, even though the user has not yet registered and then send a new invite.
I understand that invitations expire, although I should be able to specify how long they are valid in the config .
The error message that is presented to the user is rather cryptic and I believe something like
The invitation has expired.is better thanError decoding JWT..Since I am only guessing that ExpiredSignature means that the invitation has indeed expired, what is the timeframe a user has to use the invitation? Can we make this a config parameter? Would you accept a PR? Well, I'd have to dig into Rust and the code first. ;-)
I would not have expected for an invitation to expire at all, especially when
SIGNUPS_ALLOWED=false. This is why I opened this bug report.Update: I also think there should be a difference between an admin that invites a user via the admin panel and someone inviting somebody to a new (not the deafult) organization.
Deployment environment
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden:
Steps to reproduce
SIGNUPS_ALLOWED=false,SIGNUPS_VERIFY=falsein configExpected behaviour
user can register
Actual behaviour
error message
Error decoding JWT@BlackDex commented on GitHub (Oct 4, 2022):
The timeout is 5 days, and not configurable. We should indeed create a re-invite option or re-send option within the admin interface.
The ExpiredSignature kinda is descriptive enough i think, but maybe we can optimize it a bit.
@tessus commented on GitHub (Oct 4, 2022):
Thanks for the info.
I've updated the first comment, so I don't know if you have seen this part: I also think there should be a difference between an admin that invites a user via the admin panel and someone inviting somebody to a new (not the deafult) organization.
I don't know the code, so I don't know if such a differentiation would introduce unecessary complexity.
In that case it would also make sense to show in the admin panel that an invitation has expired. What do you think?
True, if somebody can read the error log. A user only gets this useless message:
Error decoding JWT.which tells them nothing. Wouldn't a more specific error message be more user friendly and useful?@BlackDex commented on GitHub (Oct 4, 2022):
That is difficult, since we need to use the invite flow from Bitwarden.
Under water we have a fake org which we use for this, so that is a bit chained.
That would be useful indeed. Maybe even a link wich changes wether the link is expired or not to re-send or re-invite.
In that case a better message would be a better option indeed.
@tessus commented on GitHub (Oct 4, 2022):
Thanks again for the explanation. I will leave this in your capable hands.
I have never coded anything in Rust, but if there's anything I can do, please point me in the right direction.
@stefan0xC commented on GitHub (Oct 4, 2022):
I actually asked exactly a year ago over on discourse how long the invitations are valid, but then only tested if they were automatically removed not if the invitations still work.
A few days ago, I started working on my feature request from back then but it's still mostly a work in progress. I ran into a dead end yesterday because I noticed that I did not actually understand how the invitations worked internally but I think I understand now and what I have to change to make it work.
@stefan0xC commented on GitHub (Oct 5, 2022):
Okay, my pull request implementing the cleanup of stale user entries is now more or less complete and ready for review. ✌️
So admin intervention should not be needed anymore (unless the invitation_purge_schedule option is configured so that the cleanup happens only at infrequent intervals).
@tessus commented on GitHub (Oct 6, 2022):
I think improving the error message would already help. I looked through the code, but this error message is very generic and broad.
I do not know how I would differentiate between a real decoding error (e.g. the token has the wrong format, the checksum is not correct, ...) and the fact that the decoding failed due to an expired token.
I only see a call to
jsonwebtoken::decodebut the error message seems to be applied to whatever error it might be.@stefan0xC commented on GitHub (Oct 9, 2022):
I've made a PR which should fix this issue in the simplest way I could think of.
For even more user friendly messages e.g.
The invitation has expired.I am not sure if it's worth the effort as the error returned bydecode_jwt(or rather byjsonwebtoken::decode) would have to be bubbled up to at least each of the 7 calling functions and handled there, if not further up as the functions might be used for different purposes (e.g.decode_inviteis not only used forregisterandaccept_invitebut also forlist_policies_token).@tessus commented on GitHub (Oct 9, 2022):
Thanks @stefan0xC for coding and thanks @dani-garcia for merging.
Even though the message does not say "invitation", I am pretty sure that users can deduct from the expired token that the invite expired. This makes it certainly a lot easier to undestand what the issue is when you do not have access to the log file on the server.
Thanks!