feat: fix calculation of token invalidation #3077

Merged
konrad merged 1 commits from dpschen/frontend:feature/fix-calculation-of-token-invalidation into main 2023-02-09 21:45:19 +00:00
Member
No description provided.
dpschen added the
kind/bug
label 2023-02-08 14:28:58 +00:00
konrad was assigned by dpschen 2023-02-08 14:28:58 +00:00
dpschen requested review from konrad 2023-02-08 14:29:06 +00:00
Member

Hi dpschen!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://3077-feature-fix-calculation-of-token--vikunja-frontend-preview.netlify.app

You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.

Have a nice day!

Beep boop, I'm a bot.

Hi dpschen! Thank you for creating a PR! I've deployed the changes of this PR on a preview environment under this URL: https://3077-feature-fix-calculation-of-token--vikunja-frontend-preview.netlify.app You can use this url to view the changes live and test them out. You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/. Have a nice day! > Beep boop, I'm a bot.
dpschen force-pushed feature/fix-calculation-of-token-invalidation from df95f1ef33 to bf957319f9 2023-02-08 14:39:31 +00:00 Compare
dpschen reviewed 2023-02-08 14:40:14 +00:00
@ -25,3 +25,3 @@
}
const expiresIn = (userInfo.value !== null ? userInfo.value.exp : 0) - new Date().valueOf() / MILLISECONDS_A_HOUR
const nowInSeconds = new Date().getTime() / MILLISECONDS_A_SECOND
Author
Member

MILLISECONDS_A_HOUR is wrong. It was originally the value 1000 which is MILLISECONDS_A_HOUR.

`MILLISECONDS_A_HOUR` is wrong. It was originally the value `1000` which is `MILLISECONDS_A_HOUR`.

Why do we need that constant anyway if we're only dealing with milliseconds -> seconds here?

Why do we need that constant anyway if we're only dealing with milliseconds -> seconds here?
Author
Member

1000 wouldn't explain why we divide through it.
The constant has the explanation in its name. but the real reason for me is mostly to be consequent. One should probably not touch the code if one doesn't know the metric 'milli'.

`1000` wouldn't explain why we divide through it. The constant has the explanation in its name. but the real reason for me is mostly to be consequent. One should probably not touch the code if one doesn't know the metric 'milli'.

That makes sense.

That makes sense.
konrad marked this conversation as resolved
dpschen reviewed 2023-02-08 14:44:17 +00:00
@ -29,3 +32,3 @@
// If the token expiry is negative, it is already expired and we have no choice but to redirect
// the user to the login page
if (expiresIn < 0) {
if (expiresIn <= 0) {
Author
Member

I'm unsure about this. Even though very unlikely I understood this as we allow tokens that are only valid another second. Would probably be best to have some buffer here.

I'm unsure about this. Even though very unlikely I understood this as we allow tokens that are only valid another second. Would probably be best to have some buffer here.

I think it does not matter much to have that buffer but it's fine to leave it in.

I think it does not matter much to have that buffer but it's fine to leave it in.
dpschen marked this conversation as resolved
dpschen reviewed 2023-02-08 14:44:33 +00:00
@ -26,2 +26,3 @@
const expiresIn = (userInfo.value !== null ? userInfo.value.exp : 0) - new Date().valueOf() / MILLISECONDS_A_HOUR
const nowInSeconds = new Date().getTime() / MILLISECONDS_A_SECOND
const expiresIn = userInfo.value !== null
Author
Member

I tried to make this part easier to understand.

I tried to make this part easier to understand.
dpschen marked this conversation as resolved
konrad merged commit d6b55c7570 into main 2023-02-09 21:45:19 +00:00
konrad deleted branch feature/fix-calculation-of-token-invalidation 2023-02-09 21:45:19 +00:00
This repo is archived. You cannot comment on pull requests.
No description provided.