# SSO bugs: still always auth\_header basic password injected & apps that need basic-email as login broken?
**URL:** https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075
**Category:** Support
**Tags:** bug, english
**Created:** [September 26, 2026, 9:24am UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075 "2026-09-26T09:24:48Z")
**Posts on this page:** 15
**Page:** 1
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 9:24am UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/1 "2026-09-26T09:24:49Z")
### I have searched the forum for similar issues
on
### This category is for general issues(=something is broken) regarding YunoHost, _NOT_ apps.
on
### This form is written in English but feel free to write in French if you’re more comfortable!
on
### What type of hardware are you using
Virtual machine
### What YunoHost version are you running
12.1.41.2
### How are you able to access your server
The webadmin
### Describe your issue
(For a bullet point list of the little “tasks” found, see later [post below](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/14).)
After noticing “half working” SSO failures (like [Login Mobilizon with LDAP is not so easy](https://forum.yunohost.org/t/login-mobilizon-with-ldap-is-not-so-easy/37746)):
A “negative” workaround (seen [here](https://forum.yunohost.org/t/mobilizon-re-enable-protect-against-basic-auth-spoofing-in-package/43059/2)) seems to be to completely disable the SSO with an app manifest setting `auth_header = false`.
I see that setting does otherwise _always_ default to `"auth_header": "basic-with-password"` in /etc/ssowat/conf.json. (Contrary to the comment “[By default, the password is not injected anymore](https://github.com/YunoHost/SSOwat/blob/a59b558bbbcaeb00199a19ce952bf3c75ce78bef/access.lua#L308)” it’s currently always overridden.)
**[EDIT: More precisely: the authorisation header is always overriden with `auth_header` and always injecting at least ‘-’ for a password. (No way to get SSO user headers without overriding the authorisation header (auth\_header = false)?]**
Further, apps that use the the email as login identifier instead of the username (like mobilizon), wouldn’t these rather need a proper override like:
“auth\_header”: “basic-_ **email** _-with-password”? (if they really accept a (basic) auth\_header for SSO)
(If they actually accept a basic auth\_header for SSO.)
### Share relevant logs or error messages
-
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 26, 2026, 1:49pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/2 "2026-09-26T13:49:38Z")
Afaiu, mobilizon generates a bearer token header which is overridden by sso (no matter what auth header is injected).
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 2:26pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/3 "2026-09-26T14:26:08Z")
Hm, sounds like another SSO bug! Because it sais:
` -- Ignore if not a Basic auth header`
( [SSOwat/access.lua at a59b558bbbcaeb00199a19ce952bf3c75ce78bef · YunoHost/SSOwat · GitHub](https://github.com/YunoHost/SSOwat/blob/a59b558bbbcaeb00199a19ce952bf3c75ce78bef/access.lua#L271) )
Maybe the header should _ **only** _ be cleared, if `find(auth_header_from_client, "^Basic%s+(.+)$")` ~~didn’t match anything~~ actually mached something (check for not equal -1?), instead of clearing any auth if there is no basic auth credential ???
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 2:42pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/4 "2026-09-26T14:42:59Z")
Hm, current code might be working fine, as ~= nil means “not equal nil” in lua? So bearer tokens are actually not cleared?
(So remaining mobilizon and others SSO problem?: Just SSO basic auth containing username not email, and mobilizon thus wanting to create new profile?)
Question: How to use yunohost CLI to custom-override the _ **nested** _ auth header setting?:
```auto
/etc/yunohost/app/.../settings.yml:
_permissions:
main:
auth_header: true
```
(trying to set \_permission.main.auth\_header did create a separate flat entry of that name)
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 26, 2026, 2:51pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/5 "2026-09-26T14:51:01Z")
In section 6, if auth\_header = true or basic-with-password, a new authorization header is built and overrides the bearer token header.
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 4:21pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/6 "2026-09-26T16:21:21Z")
“gancio” likely suffers from exacly the same SSO bug(s) as “mobilizon” (confirming post: [Gancio - only admin can login - #2 by esist0](https://forum.yunohost.org/t/gancio-only-admin-can-login/41930/2)).
(YNH SSO login [header] breaks email-based app-login.)
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 26, 2026, 4:30pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/7 "2026-09-26T16:30:58Z")
Gancio does not use SSO nor LDAP. The admin user is created via the install script.
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 5:13pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/8 "2026-09-26T17:13:07Z")
I think currenly both, stand-alone and LDAP (plus SSO) apps require `auth_header = false` to not get their own auth headers cleared. And that setting will disable any [EDIT: standard auth-header-based] SSO (it stops working).
Seems indenpendent of users being managed by the app or in LDAP.
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 26, 2026, 5:34pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/9 "2026-09-26T17:34:02Z")
> [@tmb](#):
>
> apps require `auth_header = false` to not get their own auth headers cleared.
Well… that’s already the case for many applications indeed. When needed, of course.
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 5:42pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/10 "2026-09-26T17:42:19Z")
Not sure where `auth_headers` can actually work without breaking apps, maybe with old apps only using basic auth?
Most apps would probaly required to be configurable to honor default YNH\_ proxy headers for SSO ([SSO/LDAP integration | Yunohost](https://doc.yunohost.org/en/dev/packaging/advanced/sso_ldap_integration/)) or need a custom nginx.conf to insert their accepted headers.
EDIT: Maybe change the default to ‘auth\_headers = false’?
---
### Author:  [@otm33](https://forum.yunohost.org/u/otm33)
#### Post date: [September 26, 2026, 6:25pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/11 "2026-09-26T18:25:56Z")
Take a look at `/etc/nginx/proxy_params_no_auth` and at the nginx conf for apps with auth\_header set to true.
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [September 26, 2026, 6:55pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/12 "2026-09-26T18:55:47Z")
I don’t quite understand what you try to explain, but the doc ([SSO/LDAP integration | Yunohost](https://doc.yunohost.org/en/dev/packaging/advanced/sso_ldap_integration/)) could sure use some checklist of settings to consider/set in case you know some.
It seems there are too many apps with login or SSO failing (leading e.g. to [How to use single-sign on](https://forum.yunohost.org/t/how-to-use-single-sign-on/43069)).
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [October 4, 2026, 7:26pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/13 "2026-10-04T19:26:39Z")
Maybe the authorization header should only be set if the `auth_header` value matches `basic*`?
>
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [October 5, 2026, 7:41pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/14 "2026-10-05T19:41:00Z")
Hm, it certainly seems there are a few small things with larger impact that need some clean up / refactoring in Yunohost’s central SSO code.
[SSOwat silently removes Basic Auth HTTP headers, which makes the problems it causes hard to debug. · Issue #2574 · YunoHost/issues · GitHub](https://github.com/YunoHost/issues/issues/2574)
[SSOwat (?) clashes with HTTP Basic auth · Issue #2641 · YunoHost/issues · GitHub](https://github.com/YunoHost/issues/issues/2641)
Could be easy for someone fluent in python/lua:
- Consider renaming protect\_against\_basic\_auth\_spoofing to clear\_basic\_auth\_client\_headers (just add it/document deprecation for now).
- Consider removing the central override: apps\_that\_need\_external\_auth\_maybe. (Let apps set protect\_against\_basic\_auth\_spoofing themselves as already documented, ideally according to e.g. their web/caldav client config panel setting.)
- Consider letting auth\_header = basic-mail-{with,without}-password insert email instead of username.
- Stop always overriding basic auth with truthy auth\_header setting, only override if auth\_header matches basic\* ). It currently moots protect\_against\_basic\_auth\_spoofing = false. Currently settings break either sso or webdav/caldav (app passwords).
- Consider adjusting the http info header “You’ve just been SSOed” to be more informative, e.g. SSO-INFO: basic-auth-cleared/set, user-headers-set". (To make the default/configured behavior noticable on the client side?)
---
### Author:  [@tmb](https://forum.yunohost.org/u/tmb)
#### Post date: [October 7, 2026, 6:27pm UTC](https://forum.yunohost.org/t/sso-bugs-still-always-auth-header-basic-password-injected-apps-that-need-basic-email-as-login-broken/43075/15 "2026-10-07T18:27:32Z")
Found an explanation, that might suggest a different approach to configuring the headers…
> [Set SSOWAT basic auth header stripping to false by RamanMalykhin · Pull Request #172 · YunoHost-Apps/calibreweb\_ynh · GitHub](https://github.com/YunoHost-Apps/calibreweb_ynh/pull/172) :
> This [clearing] behavior exists because some Ynh apps may want to be aware of different users and their profiles, but delegate the auth functionality entirely to SSOWat, do not integrate with LDAP in any way, and trust the header sent from SSOWat without verifying the password. Then, it would be possible to impersonate a user by setting the username manipulating the basic auth header, if this behavior did not exist.
> However, this scenario is not relevant to Calibre-Web. It does check the password
If the desired/required behavior depends on how the headers are trusted by apps, then maybe apps shoud rather be specifically configuring (requesting) something like trusted-sso-basic-auth or client-provided-basic-auth, and trusted-sso-user-headers.
I.e. don’t hardcode sso-user-header and basic-auth clearing together, and clear only what would otherwise be wrong to trust?