-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Bearer’s expires field gets scrambled after serialize → deserialize round-trip #47
Comments
I created PR with example fix |
@kilork Is there anything blocking this? I'd rather like to use this crate for our new service, but having to manually convert to and from the |
Should we try to do anything about this field actually? I am thinking about removing original field and providing the structure to use as wrapper instead. We could have ...
struct Bearer {
expires_in: Option<u64>,
...
}
...
struct BearerReceived {
bearer: Bearer,
expires_at: Option<DateTime<Utc>>,
} More simple design should be better and one who consumes library can decide, how to store it better, or use our provided wrapper. What do you think? Also we do not really use this field in library, only part responsible for token refresh. Which is most probably not used by anyone directly, as |
Personally I only care about it in that I need a reliable way to do token refreshing, but since my use-case involves ID tokens I don't necessarily need it, as you pointed out, so as long as there's a reliable way to check whether or not the token has expired then I don't really care how it's actually stored. Theoretically there might be people using OIDC without actually receiving an ID token though, but I'm not sure why anyone would. Though |
@kyrias this is the most difficult part always. To name the things. I wanted to name it so that it shows the "Bearer After Received" state, because the lifetime is counted from when the response is created, and when it is finally received - we can plot the expiration date. But of course, if it's misleading, it would be nice to have a better suggestion. |
When
Bearer
is deserialized it expects theexpires_in
field in seconds-from-now, and adds aUtc::now()
to it in order to obtain a fixed non-relative UTC instant. That makes sense.But then when it is serialized it directly serializes
expires.timestamp()
(Unix timestamp in secodns) as theexpires_in
field – which is not consistent.This means that if you save the serialized
bearer
value eg. for session keeping then each time you deserialize it you add a Unix timestampUtc::now()
worth amount of seconds to theexpires
field, making it unusable.There should be either type for the serialize-deserialize round-trip (a
SerializableBearer
type that just hasexpires
field?) or some other way to restore it from serialization.The text was updated successfully, but these errors were encountered: