Initial login/setup for TBA in docker does not work

[rpedrica]

Describe the bug

I've setup TBA in docker on a public host. According to docker logs, everything is running. However I can't get past the login screen, it just sits there without further action.

I can get to the frontend screen and am presented with 2 buttons (login / sign up for beta). Clicking login takes you to another screen (Sign in or create account)) where you can insert an email address and password. After entering the info, and clicking "Continue", the "Continue" button greys out but nothing further appears to happen on the page.

To Reproduce

1. Load the TBA homepage
2. Click on 'Log in'
3. Enter an email address and password in the respective fields
4. Click the continue button

Expected behaviour
Something should happen after clicking the Continue button like creating the account/starting a setup process/etc.

Actual behaviour
Nothing further happens after clicking Continue

Screenshots
See attached

System (please complete the following information):

• OS: Linux Slackware 15
• Browser Version Firefox 128

Additional context
server = AlmaLinux 9 with DockerCE

Adjustments to std TBA setup

• let the initial docker-compose build complete
• shutdown app and adjust env variables as follows
• bring up app again

1. set an alternate outside port for frontend in docker-compose.yml:

   ports:

   • 8095:8080

2. set the password for the mysql tba user in docker-compose.yml

3. set debug in backend .env
   LOG_LEVEL=DEBUG

4. set db secret and password in backend .env

5. set mail values in backend .env

6. set VITE variables in frontend/.env to reflect new frontend port

VITE_BASE_URL=localhost:8095
VITE_SHORT_BASE_URL=http://localhost:8095/user

** Logs **

The logs show no errors even when setting LOG_LEVEL=DEBUG in backend .env

Full docker logs output here attached.

Any assistance would be appreciated.

Regards, Robby

tba-login.txt

[rpedrica]

Further information:

I am running an NPM proxy frontend and have tried access through both the proxy and direct to the 8095 published port but the behaviour is the same. Access to port 5173 shows a JSON console with the following: Health OK

[MelissaAutumn]

Hello, thank you for the report!

We do have some basic username/password authentication support (known as password auth mode), however we recently made significant changes to our login flow, so I expect something on the frontend is broken. There's some additional blockers for self-hosting needs. Password auth mode does not have a way to create a user, and the initial setup wizard relies on connecting with Google Calendar (which requires a Google Oauth app.)

We're already planning on adding CalDav support to the setup wizard, so I'll block off time to ensure that the login flow works with password auth mode, have it create a user on first-login, and add some more documentation for self-hosters.

Finally the current docker containers are setup for local development use, I'll have to take a look at our IaC to make sure there isn't some huge issue if someone were to deploy those to a public-facing instance.

Thanks again for the report and testing it out though!

[lonesomewalker]

Seriously?
Why would i have Google Calendar?
Also, user/password management is one of the first things which is implemented...?

[rpedrica]

Hi Melissa

Thanks v much for the reply.

Can you clarify a few items:

1. how do you enable auth mode?
2. are you saying that the issue I'm having is related to not having setup a user prior to 1st run?
3. how would you setup Google Cal or auth for a self-hosted instance (if possible)?

Really interest in TBA so looking forward to a working solution, and happy to be a guinea pig for testing. I tried CalCom but was not overly impressed ...

Regards, Robby

[MelissaAutumn]

Hey there,

Password auth should be set by default. In production we use Mozilla Accounts as an identity provider (which frees us from having to mange user accounts to a certain extent 🙂)

The problem right now is there may be a bug in the frontend login code that I have to look at and fix. Once that issue and #120 are fixed you should be able to login to create a new user.

Currently the first time user experience (setup wizard) requires a Google Calendar connection (which requires a Google OAuth app from Google). We already have feedback from the beta that some people do not use Google Calendar, so we will be adding CalDav support to the wizard soon.

I'm hoping to get this stuff fixed by mid next week, but it may be a bit if other work duties come up.

Hope that helps explain the current situation!

[rpedrica]

Thanks v much!

[MelissaAutumn]

Hello @rpedrica, apologies for the delay.

This issue was fixed in #716 and requires you to stick APP_ALLOW_FIRST_TIME_REGISTER=True in your backend's .env (or server environment var). The first login (and only first login) should create a new user.

If you'd like to access the "hidden" admin interface (at /admin/subscribers) you'll need to stick APP_ADMIN_ALLOW_LIST=<your email> in your backend's .env as well.

Let me know if you run into any issues!

[rpedrica]

Melissa,

Thanks v much, but this doesn't seem to have made any difference on my end. I've done the following:

1. removed my old appointment folder
2. did a new git clone https://github.com/thunderbird/appointment
3. copied my old frontend/.env, backend/.env and compose files to the new appointment folder (I checked for any diffs)
4. add the following:

APP_SETUP=True
APP_ALLOW_FIRST_TIME_REGISTER=True
APP_ADMIN_ALLOW_LIST=[email protected]

5. do startup: docker-compose up -d --build

I still get the login screen where I put my email address and password in, click continue and nothing happens. I can get to the subscribers screen but it just says "Sorry, this page requires you to be logged in."

My docker logs b.t.w. indicate on startup:

backend-1 | 2024-11-01 14:09:51 DEBUG Logger started!
backend-1 | Checking if we need to run first time setup...
backend-1 | Setting up env!
backend-1 | Finished running first time setup!
backend-1 | 2024-11-01 14:09:53 DEBUG Logger started!

... so this is definitely a new install.

Regards, Robby

[MelissaAutumn]

Hmm odd! What does the main route for the backend return (usually http://localhost:5173/), Health OK or Health BAD?

[rpedrica]

I have that port listening:

ss -ltn =
0.0.0.0:5173

But trying to get anything from it throws an error:

curl http://localhost:5173/
curl: (56) Recv failure: Connection reset by peer

and

curl http://:5173
curl: (7) Failed to connect to port 5173: Connection refused

I see in the config it's set to listen on localhost only ...

I thought maybe the port might be in use elsewhere and causing a conflict but shutting down TBA dockers causes the port to disappear so it's definitely linked.

I'm including my sanitised config/log files here.

Regards, Robby

tba-backend-env.txt
tba-compose.yml.txt
tba-frontend-env.txt
tba-log.txt

[MelissaAutumn]

The backend binds to 0.0.0.0:5173 by default (so all available addresses), and looks you're running into a weird bug with database initialization. Can you try re-starting the docker script and seeing if your backend gets past:

backend-1   | Initializing database, and setting it to the latest revision
backend-1   | INFO  [alembic.runtime.migration] Context impl MySQLImpl.
backend-1   | INFO  [alembic.runtime.migration] Will assume non-transactional DDL.

Since this has been only occuring on database initialization (and not existing databases) I haven't had the time to look into why it stalls and haven't had luck with existing work-arounds for this bug.

[MelissaAutumn]

Hello! I've pushed up a change that should fix this stall. Please pull the latest changes and let me know if that fixes your issue.

Thanks!

[rpedrica]

Thanks Melissa

But seems the same behaviour - is there a certain branch I should be using for this (other than main)?

My latest docker logs:

tba-log2.txt

Also, the backend/.env file by default might have an issue:

APP_ADMIN_ALLOW_LIST=
True

I think this statement is supposed to be 1 line but I've just been commenting it out and putting my own in:

#APP_SETUP=True
APP_ALLOW_FIRST_TIME_REGISTER=True
APP_ADMIN_ALLOW_LIST=

Also, if I enable APP_SETUP=True, this appears to tell TBA that the app has been setup already ... so I'm leaving that commented as well.

Regards, Robby