Long time, regular main user being asked to Confirm Email Address

So all of a sudden, my regular user is being asked to confirm my email address. ??

Pressing the Confirm button in the email (March 8 2021) obviously returns the error that the token is expired.

I can get into the db… is there a setting to “recognize” the email again?? I’m stuck.

Thank you!

Ok, I figured out how to get back in but I still don’t know why this change in my regular user’s status happened.

Thankfully Cloudron allows access to all kinds of background goodies. In this case, what was important is the PostgreSQL db. So, off to learn to some psql commands!

I figured out I had to deal with two bits of info in two columns. The is_active column and the email_confirm_token.

Using the following I could UPDATE the is_active from ‘f’ to ‘t’:
UPDATE users SET is_active='t' WHERE id='1';

I thought this would be enough to get me in, but when the login page was still asking for the email confirmation, I looked in the db and realized that the email_confirm_token still had something. So, I checked the earlier confirmation email, which was
https://myvikunja.install.com?userEmailConfirm=longstring, and replaced the longstring with the data still in the db column of email_confirm_token, and put that into the browser. Voila, I was then (re)confirmed, and could log in. Phew. I was really worried a good day’s work was lost.

I supposed I could have also just nulled the new long string, but I was worried this would introduce some other weirdness.

But, WHY this reset on my user??

The one place where this could happen would be if you’ve changed your email address.
The other would be through the vikunja change-status <id> command.

When you log in, it should only check if the is_active is set to false or not and shouldn’t care about the content of the email_confirm_token. It could be the email you’ve received now got stuck somewhere and actually did take 6 weeks for delivery.

Also, the token does not expire so I’m wondering where you got that error message from (yeah I know, they should expire - that’s definitely something to improve).

What version are you on?

Vikunja 0.16.1

Unfortunately, even though I posted how I fixed the problem, I have no idea in what order the problem developed. At one point I entered my email in the Reset Password box, thinking that might let me login, but I entered it incorrectly. I had to do the PostgreSQL magic to change that. But the lock out happened before this. So when did that email token show up?? Before my attempted Reset? Or was it already there when the first time I couldn’t login happened? Anyway, as I mentioned, I can login now.

The only other problem is that I can’t login from the Windows app, installed by Chocolate. Oh well.

Definitely does not make sense. If it is reproducible it might be worth trying with the unstable version.

TIL Vikunja is on chocolatey :sweat_smile:
Does it work with the version from us directly? desktop | S3 Browser

Sadly no. However, I’ve since run into another problem. I can’t login at all. The app just suddenly decided to not respond, refreshed the page which brought to the login page, but now… nothing. I’m looking for help elsewhere at the moment, but I am sure I’ll be back here eventually.
It’s too bad. I really like this app, but twice now it just suddenly crapped out on me. I dare not commit more time or data to this.

Is the api reachable from the browser?

You, I am running Vikunja from within a Cloudron installation. It has been running fine for quite awhile. It’s strange that suddenly something goes wrong.

In this case, in the logs revealed an error parsing the time zone in the config.yml. Why would this be a problem all of a sudden? The time zone was GMT+1. So, I changed it to just GMT, restarted Vikunja, and now it works.

Same thing with the previous problem I shared here: My user couldn’t log in, and the database showed a reset token which I needed to deal with. No idea how that happened.

I worry when the next sudden problem will arise, and if it will be unsolvable. I’ve put alot of time into Vikunja so far… but these weird errors make me nervous.

It could be a regression issue with the time zone parsing or the way cloudron builds their package. I’ll take a look.

The time zone issue does not explain why the user’s password is reset all of a sudden though.

Anything else in the logs from when the app did not respond at all?

Unfortunately, I have no memory nor record of the GMT change.

Here are the logs when I wasn’t able to login:

May 06 13:17:33 box:settings initCache: pre-load settings
May 06 13:17:33 box:taskworker Starting task 7570. Logs are at /home/yellowtent/platformdata/logs/51667508-ab88-4d9d-ba18-be51560acaad/apptask.log
May 06 13:17:33 box:tasks 7570: {"percent":2,"error":null}
May 06 13:17:33 box:apptask vikunja.example.com startTask installationState: pending_restart runState: running
May 06 13:17:33 box:tasks 7570: {"percent":20,"message":"Restarting container"}
May 06 13:17:34 2021-05-06 11:17:34,060 WARN received SIGTERM indicating exit request
May 06 13:17:34 2021-05-06 11:17:34,061 INFO waiting for nginx to die
May 06 13:17:35 2021-05-06 11:17:35,100 INFO stopped: nginx (exit status 0)
May 06 13:17:36 ==> Changing ownership
May 06 13:17:36 ==> Configuring vikunja-api
May 06 13:17:36 box:tasks 7570: {"percent":100,"message":"Done"}
May 06 13:17:36 box:apptask vikunja.example.com updating app with values: {"installationState":"installed","error":null,"health":null}
May 06 13:17:36 box:taskworker Task took 3.191 seconds
May 06 13:17:36 box:tasks setCompleted - 7570: {"result":null,"error":null}
May 06 13:17:36 box:tasks 7570: {"percent":100,"result":null,"error":null}
May 06 13:17:48 ==> Starting vikunja frontend and API using supervisor
May 06 13:17:48 2021-05-06 11:17:48,745 CRIT Supervisor is running as root. Privileges were not dropped because no user is specified in the config file. If you intend to run as root, you can set user=root in the config file to avoid this message.
May 06 13:17:48 2021-05-06 11:17:48,745 INFO Included extra file "/etc/supervisor/conf.d/nginx.conf" during parsing
May 06 13:17:48 2021-05-06 11:17:48,745 INFO Included extra file "/etc/supervisor/conf.d/vikunja-api.conf" during parsing
May 06 13:17:48 2021-05-06 11:17:48,752 INFO RPC interface 'supervisor' initialized
May 06 13:17:48 2021-05-06 11:17:48,752 CRIT Server 'unix_http_server' running without any HTTP authentication checking
May 06 13:17:48 2021-05-06 11:17:48,753 INFO supervisord started with pid 1
May 06 13:17:49 2021-05-06 11:17:49,757 INFO spawned: 'nginx' with pid 216
May 06 13:17:49 2021-05-06 11:17:49,761 INFO spawned: 'vikunja-api' with pid 217
May 06 13:17:50 172.18.0.1 - - [06/May/2021:11:17:50 +0000] "GET / HTTP/1.1" 200 1417 "-" "Mozilla (CloudronHealth)"
May 06 13:17:50 Error parsing time zone: unknown location GMT+12021/05/06 11:17:50 Using config file: /app/code/api/config.yml
May 06 13:17:50 2021/05/06 11:17:50 Redis initialized
May 06 13:17:50 2021-05-06 11:17:50,114 INFO exited: vikunja-api (exit status 1; not expected)
May 06 13:17:51 2021-05-06 11:17:51,116 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
May 06 13:17:51 2021-05-06 11:17:51,120 INFO spawned: 'vikunja-api' with pid 235
May 06 13:17:51 2021/05/06 11:17:51 Using config file: /app/code/api/config.yml
May 06 13:17:51 2021/05/06 11:17:51 Redis initialized
May 06 13:17:51 Error parsing time zone: unknown location GMT+12021-05-06 11:17:51,436 INFO exited: vikunja-api (exit status 1; not expected)
May 06 13:17:53 2021-05-06 11:17:53,442 INFO spawned: 'vikunja-api' with pid 243
May 06 13:17:53 2021/05/06 11:17:53 Using config file: /app/code/api/config.yml
May 06 13:17:53 2021/05/06 11:17:53 Redis initialized
May 06 13:17:53 Error parsing time zone: unknown location GMT+12021-05-06 11:17:53,698 INFO exited: vikunja-api (exit status 1; not expected)
May 06 13:17:56 2021-05-06 11:17:56,706 INFO spawned: 'vikunja-api' with pid 253
May 06 13:17:56 2021/05/06 11:17:56 Using config file: /app/code/api/config.yml
May 06 13:17:56 2021/05/06 11:17:56 Redis initialized
May 06 13:17:56 Error parsing time zone: unknown location GMT+12021-05-06 11:17:56,981 INFO exited: vikunja-api (exit status 1; not expected)
May 06 13:17:57 2021-05-06 11:17:57,983 INFO gave up: vikunja-api entered FATAL state, too many start retries too quickly
May 06 13:18:00 172.18.0.1 - - [06/May/2021:11:18:00 +0000] "GET / HTTP/1.1" 200 1417 "-" "Mozilla (CloudronHealth)"

As it turns out, you can’t use gmt offsets in the time zone configuration. I’ve updated the docs to clarify that: Config options | Vikunja
Time zones have to be in the official tz database names. In your case something like Europe/London should work.