Return expiring date after Login

[VolkerSchiewe]

Is there a reason why only the user is returned along with the token and not also the expiring date or the expiring time-delta?

It could be very helpful to have this information to validate tokens in the frontend before using them.

[johnraz]

Could you elaborate a bit more?

What would be the usecase exactly?

What kind of validation should be done on a freshly generated token?

Thanks!

[belugame]

I see a use case where you have a long running client application that is desired to auto refresh it's tokens as long as the user is active (uses mouse, clicks etc) but does not necessarily interact with the backend.

[johnraz]

@belugame: that's a valid use case indeed.

I think we could simply setup a refresh token expiry endpoint that makes use of the auto-refresh feature behind the scene by forcing a refresh and return a simple payload like:

{
    token_expiry: <datetime>
}

We then could also add this in the payload returned by the login view.

If everybody agrees I'm up to implement it in the coming days 😉

[belugame]

sounds good to me, go for it :)

[VolkerSchiewe]

The use case @belugame described is what i was thinking of: Long running client application, that know when the token is going to expire and can refresh it, or redirect the user to the login page.

The main idea was to get the expiring datetime together with the token.

[johnraz]

@VolkerSchiewe: great! it aligns with what I plan to do.

I hope to have some time soon to get my hands on this 👍

[abdelwahebmoalla]

Hey @johnraz is this feauture coming soon?

[johnraz]

It’s still on my radar yes but I can’t give you a specific ETA.

[sphrak]

@VolkerSchiewe @abdelwahebmoalla just letting you know PR #152 aims to solve what you guys are looking for :)

[johnraz]

@belugame: I suggest we close this and continue work in #156