Is it possible to disable "Guest sign-in with password"?

[miliyah]

Hello!

I tried setting "AUTH_ALLOW_PASSWORD_LOGIN" to "false" to make SSO the only way in, but I can still see the guest sign-in with password option.

I am using yuvomi through Docker Compose.

Is there another setting I don't know of to turn it off too?

[ulsklyc]

There is no second setting - you found a real bug, and it has two halves that are worth keeping apart, because one of them is deliberate and the other is mine.

The exemption is intentional

AUTH_ALLOW_PASSWORD_LOGIN=false applies to the household. Shared expenses can involve people who are not in it: a neighbour settling a bill, a friend on a shared trip. An admin creates such an account with a password, and those people have no entry in the household's identity provider - there is nothing for them to sign in with (#847). So the server exempts them from the switch by design. Without that exemption, turning on SSO-only would have silently bricked every guest account, including existing ones.

That part stays.

Showing it unconditionally was the bug

The login page never asked whether your household has any such guest. It saw "password login is off" and offered the guest route, full stop. Yours has none, so you were looking at an entrance nobody can walk through - and from the outside that is indistinguishable from an open one. Reading it as a hole in the bolt you had just closed was the correct reaction.

Fixed. The server now answers the question the page failed to ask. GET /api/v1/auth/oidc/config gained one field, guest_password_login_enabled, and the button appears only when it is true. Two details in how it answers:

• It is one bit. It says "there are guests", never who or how many.
• It is only computed where the question arises. With password login open, the field is false without the guest table ever being read - the form is showing anyway. So on a normal installation the public endpoint reveals nothing it did not already reveal.

Measured both cases against a running server in your configuration (OIDC configured, AUTH_ALLOW_PASSWORD_LOGIN=false, a linked SSO admin):

Household	Endpoint	Login page
no split-expense guests	guest_password_login_enabled: false	SSO button only
one guest	guest_password_login_enabled: true	guest route offered

So on your instance the page will show the SSO button and nothing else.

One thing worth checking on your side, because it produces the same symptom for a different reason: the switch only takes effect once a linked SSO administrator exists - an admin account that has actually signed in through your provider at least once. Until then it deliberately falls open, so that a household cannot lock itself out of its own administration. If your login form is still fully visible rather than just the guest link, that is what you are seeing, and the server log says so at startup. GET /api/v1/auth/oidc/config tells you directly: password_login_enabled should be false.

Not released yet - it will be in the next release. Thanks for the report; the exemption was right and its presentation was not.

[ulsklyc]

Released in v2.59.0. @miliyah - after updating, your login page will show the SSO button and nothing else. There is no additional setting to find; the button you were seeing should simply be gone.

To recap what changed, since the answer had two halves: the exemption for split-expense guests stays, because those are external people with no account in your identity provider. What was wrong is that it was offered to every household, including those with no such guests - an entrance nobody could walk through, which is indistinguishable from an open one from the outside.

If the full login form is still there rather than just the guest link, that is a different mechanism and worth checking: the switch only takes effect once an administrator account has actually signed in through your provider at least once. Until then it deliberately falls open so a household cannot lock itself out of its own administration, and the server says so at startup. GET /api/v1/auth/oidc/config answers it directly - password_login_enabled should read false.

Closing this. Thanks for the report - the exemption was right and its presentation was not, and that distinction only became visible because you asked.