REVERSE_PROXY_AUTH logs user in but does not allow creation of new babies

[prometheanfire]

I'm using authelia and traefik on kubernetes at the moment. Running 1.13.2.
I'm seeing no errors in the nginx logs (all 200s).

CSRF_TRUSTED_ORIGINS=http://127.0.0.1:8000,https://babybuddy.mydomain
SECURE_PROXY_SSL_HEADER=true
REVERSE_PROXY_AUTH=true
ALLOWED_HOSTS=https://babybuddy.mydomain
SECRET_KEY=is set

The children dropdown is blank, the dashboard/welcome page states there should be a button below to add a child also shows nothing. I'm not sure why this is happening, is do I need to do anything extra to tag the users managed by the Remote-User header for actual use?

Also, the correct username is populated in the to right corner and I can set first/last name, etc.

[cdubz]

Hm -- are you able to access the "Database Admin" area (/admin/) with the user (or bypassing the proxy)? From there you could check the relevant user to confirm they have both the "Staff" and "Super user" flag.

[prometheanfire]

I'm able to access the admin page but it wants me to log in as admin, not my user.

I'm looking at the slqite db now. It has my user but I don't think it's flagged as admin (not sure what the table columns are tied to).

2||2022-10-26 19:42:06.671761|0|usernamehere|||0|1|2022-10-26 19:41:31.176732|

[cdubz]

Yeah it looks like that is missing one of the two flags... I'm not entirely sure how that works for a reverse proxy auth so will need to get something setup to test this out.

[prometheanfire]

oh, the sqlite-manager addon for firefox helps a bit, my user is not flagged as a superuser or as staff. I'm guessing that the logic behind the Remote-User stuff in the app does not flag the user as anything but read-only.

[prometheanfire]

so, here's the workaround for now...

kubectl -n NAMESPACE-GOES-HERE cp POD-NAME-GOES-HERE:/config/data/db.sqlite3 db.sqlite3

then run the following query against the db
update "auth_user" set is_superuser=1, is_staff=1 where username="USERNAME-GOES-HERE"

then copy the db back
kubectl -n NAMESPACE-GOES-HERE cp db.sqlite3 POD-NAME-GOES-HERE:/config/data/db.sqlite3
kubectl -n NAMESPACE-GOES-HERE exec POD-NAME-GOES-HERE -- chown abc:abc /config/data/db.sqlite3

[Anoerak]

If you're not a super user or staff, you'll need to select the actions authorized for this account in order to be able to access datas and functions (such as add an extra baby).
Using reverse proxy for https on my NAS and everything's working fine.

[prometheanfire]

There was no user set up to be able to grant other users admin/staff. Since all users were through the reverse proxy auth Remote-User header and the header does not grant the admin or staff tag to those reverse proxy auth'd users, no user had the tag. That said, looking at the DB I did see an admin user but that was not managed by anything I set up.

[cdubz]

That said, looking at the DB I did see an admin user but that was not managed by anything I set up.

Baby Buddy provides a default user with username and password admin.

[prometheanfire]

I can't get access to that user when using the reverse auth. If I try to sign out and back in with the admin user it will sign me in as the user sent by the Remote-User header.

[Anoerak]

Did you try to connect through the admin portal (the base url/admin eg:https://www.my_url.com/admin) with the admin credential (login admin password admin)?

[cdubz]

Did you try to connect through the admin portal (the base url/admin eg:https://www.my_url.com/admin) with the admin credential (login admin password admin)?

@prometheanfire is saying that's not possible with the reverse proxy, which makes sense.

I'm not quite sure how Django's base handling of reverse proxy users works here. It seems we would want to follow the same pattern as a regular user (with both staff and superuser access assigned to the user) but we'll need to verify if that's a concern and if it's even possible with Django's tooling.

[cdubz]

@prometheanfire looking at this a bit closer, you should still be able to log in with the admin account by not setting the Remote-User HTTP header. The way the app is configured, it will fall back on the regular authentication flow so you should then be able to to go to /login and login with the default user and password.

If you're not able to do that for some reason, the other option would be to create a user from the command line with the --is-staff flag and a username matching whatever value will be present in your Remote-User header. Then the proxy auth should work with your user as an admin.

[prometheanfire]

Ya, I'd need to bypass the proxy somehow, would have to disable ALLOED_HOSTS for it I think. https://docs.baby-buddy.net/configuration/security/#allowed_hosts

as for creating users via the command line, that's what I tried at first but it didn't work (createuser not working)

pwd; python3 manage.py createuser --help
/app/babybuddy
No Django settings specified.
Unknown command: 'createuser'
Type 'manage.py help' for usage.

the place I'm running it from is a container maintained by https://hub.docker.com/r/linuxserver/babybuddy and seems to run it via gunicorn. https://github.com/linuxserver/docker-babybuddy
so that's probably a downstream issue

[cdubz]

Ah yeah you need to also set the env var DJANGO_SETTINGS_MODULE to babybuddy.settings.base when you run the createuser command.

[prometheanfire]

yep, that'll work. this works in kubernetes at least

kubectl --namespace babybuddy exec babybuddy-86cdd4c587-jxvjb -- sh -c 'DJANGO_SETTINGS_MODULE=babybuddy.settings.base python3 /app/babybuddy/manage.py createuser --help'

Should there be an issue to update docs about the need for that var to be set for the managing users section?

[cdubz]

Yeah -- couldn't hurt to update the docs to make that more clear. Basically any management command needs that env var set but createuser is probably the only one that will get much exposure to non-developer use. Adding it to that section would make sense.