Invalid auth token does not log user out #1757

New Issue

azymondrian · 2020-12-15T03:23:19Z

azymondrian commented

2020-12-15 03:23:19 +00:00

If I restart the API server (in docker) all current JWTs are invalidated, but they're not expired yet so the frontend doesn't logout. I have to manually logout in order to get back to the login screen and get a new token.

This is evidenced by a bunch of 401 errors on API calls and nothing loading (similar to #317)

It would be nice if there was a re-auth required popup or something, or at least an auto redirect to the login screen.

Partial Fix

If I add ctx.dispatch('logout') after auth.js:187 it will force a logout at least by the next page refresh

Other thoughts

I've been looking around at how this could be implemented but the best idea I've had is to add something to each HTTP...catch block. Not sure if that's the best.

If I restart the API server (in docker) all current JWTs are invalidated, but they're not expired yet so the frontend doesn't logout. I have to manually logout in order to get back to the login screen and get a new token. This is evidenced by a bunch of 401 errors on API calls and nothing loading (similar to [#317](https://kolaente.dev/vikunja/frontend/issues/317)) It would be nice if there was a re-auth required popup or something, or at least an auto redirect to the login screen. ##### Partial Fix If I add `ctx.dispatch('logout')` after [auth.js:187](https://kolaente.dev/vikunja/frontend/src/branch/master/src/store/modules/auth.js#L187) it will force a logout at least by the next page refresh ##### Other thoughts I've been looking around at how this could be implemented but the best idea I've had is to add something to each HTTP...catch block. Not sure if that's the best.

konrad commented

2020-12-15 11:33:16 +00:00

First of all, you should configure a jwt secret to prevent token invalidation after restarting the container. If you don't do that, Vikunja will generate a new random secret at startup which is what invalidates the previously issued tokens.

There is a check which logs the user out if the token expired, but not when renewing failed. I've added your suggestion in 51bbad9794 since it sounded like a good idea. Now the user will be logged out if the token could not be renewed. If you manually reload the page after the jwt secret changed, this will still yield an error but will properly log out the user. I still think the best way to prevent these error messages is to prevent the token from expiring by renewing it, but for that you should configure a jwt secret server side.

Could you check the newest version from my commit above to see if the error persists? A release should be ready shortly.

First of all, you should configure a [jwt secret](https://vikunja.io/docs/config-options/#service) to prevent token invalidation after restarting the container. If you don't do that, Vikunja will generate a new random secret at startup which is what invalidates the previously issued tokens. There is a check which logs the user out if the token expired, but not when renewing failed. I've added your suggestion in https://kolaente.dev/vikunja/frontend/commit/51bbad979448c4548631a801996c93e6234a0553 since it sounded like a good idea. Now the user will be logged out if the token could not be renewed. If you manually reload the page after the jwt secret changed, this will still yield an error but will properly log out the user. I still think the best way to prevent these error messages is to prevent the token from expiring by renewing it, but for that you should configure a jwt secret server side. Could you check the newest version from my commit above to see if the error persists? A release should be ready shortly.

konrad added the

kind/bug

label 2020-12-15 11:33:22 +00:00

azymondrian commented

2020-12-15 23:38:53 +00:00

Ah, I missed that config option!

It looks like the random secret is generated in after-install.sh, I'm assuming I should use this command to generate what I pass as config?

Thanks for your response and I'll be able to test that commit soon.

Ah, I missed that config option! It looks like the random secret is generated in [after-install.sh](https://kolaente.dev/vikunja/api/src/commit/618353bf95cc10b78d469d66fc49b1adf6c98280/build/after-install.sh#L4), I'm assuming I should use this command to generate what I pass as config? Thanks for your response and I'll be able to test that commit soon.

konrad commented

2020-12-15 23:48:58 +00:00

No, the random secret is set directly in the config at https://kolaente.dev/vikunja/api/src/branch/master/pkg/config/config.go#L209 - after-install.sh is only executed once (after installing) for debian and rpm packages.

You can pass it whatever you like. A good secret follows the usual password rules and has at least 32 characters. pwgen works great to generate one.

No, the random secret is set directly in the config at https://kolaente.dev/vikunja/api/src/branch/master/pkg/config/config.go#L209 - `after-install.sh` is only executed once (after installing) for debian and rpm packages. You can pass it whatever you like. A good secret follows the usual password rules and has at least 32 characters. `pwgen` works great to generate one.

azymondrian commented

2020-12-15 23:57:52 +00:00

Good to know, thank you! Setting the VIKUNJA_SERVICE_JWTSECRET env in my docker-compose.yml has fixed the root issue of invalidating all the JWTs on restart.

Your patch is also working, I was successfully logged out after refreshing. You don't need to rush out a a new release for me though, I currently have a custom build running anyways and already pulled it in :)

I did still see some 401 errors when causing other API calls (like changing pages), but that isn't as annoying if refreshing fixes things.

Good to know, thank you! Setting the VIKUNJA_SERVICE_JWTSECRET env in my docker-compose.yml has fixed the root issue of invalidating all the JWTs on restart. Your patch is also working, I was successfully logged out after refreshing. You don't need to rush out a a new release for me though, I currently have a custom build running anyways and already pulled it in :) I did still see some 401 errors when causing other API calls (like changing pages), but that isn't as annoying if refreshing fixes things.

konrad commented

2020-12-16 00:17:01 +00:00

You don't need to rush out a a new release for me though, I currently have a custom build running anyways and already pulled it in :)

I thought so :upside_down: I think the root issue here has been introduced since the last release anyway so the last release should still not have that issue (that is, as long as you have a jwt secret configured)

I did still see some 401 errors when causing other API calls (like changing pages), but that isn't as annoying if refreshing fixes things.

The other api calls are coming from loading the lists overview for the menu on the left and whatever you currently have open. I think this is fine since the token is most likely invalidated after the tab hasn't been active for a long time which means Vikunja would notice this only after a page reload (or re-focus) in which case it will log the user out. Also to really fix this we'd need to check after every request which would get annoying quite quickly, as you already figured out.

I'm closing this issue since it seems to be resolved, feel free to reopen if you have any issues.

> You don't need to rush out a a new release for me though, I currently have a custom build running anyways and already pulled it in :) I thought so :upside_down: I think the root issue here has been introduced since the last release anyway so the last release should still not have that issue (that is, as long as you have a jwt secret configured) > I did still see some 401 errors when causing other API calls (like changing pages), but that isn't as annoying if refreshing fixes things. The other api calls are coming from loading the lists overview for the menu on the left and whatever you currently have open. I think this is fine since the token is most likely invalidated after the tab hasn't been active for a long time which means Vikunja would notice this only after a page reload (or re-focus) in which case it will log the user out. Also to really fix this we'd need to check after every request which would get annoying quite quickly, as you already figured out. I'm closing this issue since it seems to be resolved, feel free to reopen if you have any issues.

konrad closed this issue

2020-12-16 00:17:05 +00:00

konrad referenced this issue from vikunja/frontend

2020-12-16 00:17:40 +00:00

Session expiry does not redirect to the login page #1756

xeruf commented

2022-07-20 19:36:42 +00:00

Using current unstable (and I think it was the same in stable), this seems to be broken. The error message pops up, but I am not logged out properly :/

konrad commented

2022-07-21 13:35:39 +00:00

It looks like this only happens when a list with a background has recently been visited and it tries to load the list background after logging out.

konrad referenced this issue from a commit

2022-07-21 13:53:17 +00:00

fix: don't try to load lists after logging out

konrad commented

2022-07-21 13:53:59 +00:00

I've fixed this particular error in 4c560f1a03 but there might be more like it in the future. Please report back if you find any.

I've fixed this particular error in https://kolaente.dev/vikunja/frontend/commit/4c560f1a031c21a3e735bdbad061b284a03b6618 but there might be more like it in the future. Please report back if you find any.

konrad referenced this issue from a commit

2024-02-07 14:00:33 +00:00

chore(deps): update dependency sass to v1.49.11 (#1757)

Sign in to join this conversation.