[HOMEASSISTANT] Le flux de configuration n'a pas pu être chargé: 401: Unauthorized

[Ugo]

Bonjour,

Merci pour l’application, je viens de l’installer et je rencontre un problème persistant.
J’ai parcouru toutes les topics en lien et chercher dans les logs disponibles mais je ne trouve pas de solution.

Mon serveur YunoHost

Matériel: Serveurs à la maison type Intel NUC
Version de YunoHost: 11.2.8.2
J’ai accès à mon serveur : En SSH et Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non mais je l’upgrade depuis quelques années
Si oui, expliquer:
Si votre requête est liée à une applicatio, précisez son nom et sa version:
name: Home Assistant
version: 2023.12.3~ynh1

Description du problème

J’ai fait une installation classique, aucune autre action. J’arrive à accéder à l’interface, à me loguer avec mon user.
Après dès que je cherche à faire une action de type : configurer un appareil découvert, ajouter un appareil, ajouter une intégration, etc j’ai toujours le même message :

023-12-22 14:32:18.600 WARNING (MainThread) [homeassistant.components.http.ban] Login attempt or request with invalid authentication from MONIPPUB. Requested URL: '/api/config/config_entries/flow/607bda5efd5d3bb3dd66b334caa70669'. (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36)

(J’ai “anonymisé” mon IP dans le message)
J’ai essayé depuis plusieurs réseaux dont le mien à la maison => même message
J’ai essayé depuis plusieurs navigateurs : firefox, brave, edge => même message
J’ai désactiver mon gestionnaire de mot de passe en auto => même message
J’ai essayé en mode privé => même message
J’ai regardé les confs nginx suggérés mais elles semblent déjà en place

Je dois dire que je sèche une peu, si quelqu’un à une idée de ce que je pourrais tester ?

D’avance, merci

[rungeard]

Utilises-tu firefox ?

J’ai eu le même problème à l’époque. Un soucis avec Firefox et les websockets. Essai avec un autre navigateur et si ca devrait ne plus afficher l’erreur.

[Ugo]

Bonjour,

Merci pour la réponse et la suggestion.
Malheureusement comme indiqué j’ai testé sur firefox, Chrome ou Edge en mode privé ou non et le résultat est toujours le même.

[wbk]

Bonjour Ugo,

Bienvenue sur forum!

@Ugo

si quelqu’un à une idée de ce que je pourrais tester ?

I had a look on the neighbouring forum, that one of Homeassistant. The same problem pops up there. Their suggestion: add a few parameters to the nginx-config:

you need to add

            proxy_set_header    Upgrade     $http_upgrade;
            proxy_set_header    Connection  "upgrade";

to the “location” tag

Coincidentally, I had to make a similar change just last week for another app, Uptime Kuma. I forgot the reason for the upstream change though.

[OniriCorpe]

This doesn’t seem to be the problem here, the nginx configuration of the homeassistant_ynh package is correct (lines 10 and 11) and complies with the Home Assistant example configuration (lines 67 and 68)

[Ugo]

Bonjour,

Merci pour vos réponses mais j’ai effectivement déjà cette configuration nginx de base mais qui semble coller avec le patch mentionné dans plusieurs topics :

location / {
	proxy_pass http://localhost:8123;
	proxy_set_header Host $host;
	proxy_redirect http:// https://;
	proxy_http_version 1.1;
	proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection $connection_upgrade;
	proxy_set_header X-Forwarded-Host $host;

	# Include SSOWAT user panel.
	include conf.d/yunohost_panel.conf.inc;

[wbk]

On the one hand it is nice of course that the Yunopackage is already updated with that patch, but now we have to look for another solution.

I have no idea about nginx directives. For Uptime Kuma I had a similar problem, there Gildas had a suggestion with slightly different options for nginx.

@Gildas

proxy_set_header   X-Real-IP $remote_addr;
proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;

besides, I had to add

@wbk

proxy_set_header Host $host;

Two of these are already in your location block, but X-Real-IP is not there yet. Perhaps it needs to know your actual IP to keep the authorized session attached to it?

It is only a guess… Maybe things get worse when applying these options.

I hope another reader has better suggestions!

[Gildas]

The HomeAssistant example configuration linked above uses $http_host, not $host.

Can you try to change proxy_set_header Host and proxy_set_header X-Forwarded-Host lines to use $http_host ?

Then, test your configuration with nginx -t and reload the webserver with systemctl reload nginx

[OniriCorpe]

@Gildas

The HomeAssistant example configuration linked above uses $http_host, not $host.

It’s a security thing, but I don’t remember exactly what it does
But it works almost the same, it would be very surprising if it came from there

[Ugo]

Merci pour les suggestions. J’ai testé mais ça ne semble pas mieux : même message d’erreur. Je dois avoir une configuration particulière si personne ne reproduit l’erreur mais je ne trouve pas laquelle.

J’ai essayé également de forcer la résolution du domaine sur l’IP interne quand je suis dans mon réseau pour ne pas repasser par l’extéireur mais pas mieux…

Pour tester j’ai désactivé fail2ban et ufw, ce n’est pas mieux.

Est-ce que vous pensez que cette directive en ajoutant loclahost pourrait changer quelque chose ?

trusted_proxies:
    - 127.0.0.1
    - ::1

Je ferai d’autres tests en début de semaine prochaine, en attendant merci pour votre aide et de bonnes fêtes

[manu-l]

Bonjour,

J’ai le même problème, je pensais que c’était un pb de droits utilisateur mais je n’ai rien trouvé qui puisse aider.
Je peux faire des tests si ça aide

Merci et bonnes fêtes

[Ugo]

Bonjour,

Je suis reparti sur:

• une désinstallation / réinstallation de l’application avec redémarrage entre les 2.
• je n’ai pas touché à la configuration proposée (hormis les infos de latitude, altitude, etc …)
• Installation d’un Chrome à jour sans extension.
• firewall désactivé

Toujours cette erreur 401 à chaque action de configuration.
Est-ce qu’il n’y pas un moyen d’activer des logs un peu plus verbeux ?

[Ugo]

Le temps d’écrire le message que j’ai réussi à le faire fonctionner…

Je suis repassé sur mon navigateur Brave sur lequel çe ne fonctionnait pas et là ça marche. Par contre ça ne fonctionne toujours pas sur un Chrome à jour sans extension, cache vidé…

Je m’oriente donc vers un problème de navigateur pourtant c’est la première chose que j’avais testée en passant sur Firefox, Brave et Edge en mode privé ou a normal.

Bref je vais faire plus de tests pour essayer de comprendre tout ça qui reste flou pour l’instant pour moi.
J’essaie de vous donner mes conclusions.

Merci pour l’aide apportée et désolé pour le dérangement.

[ewilly]

@Ugo

Est-ce qu’il n’y pas un moyen d’activer des logs un peu plus verbeux ?

oui c’est possible :

1. au niveau du service : ajouter --verbose à la fin de la ligne commençant par ExecStart= dans /etc/systemd/system/homeassistant.service et checker les logs avec journalctl -f -u homeassistant

2. au niveau du script d’authentification : remplacer #DEBUG=1 par DEBUG=1 dans
   /home/yunohost.app/homeassistant/bin/ynh_ldap-auth.sh et checker les logs crées dans /home/yunohost.app/homeassistant/bin/ldap-auth.log

[Ugo]

Bonjour,

Pour clore mon sujet, après quelques tests je suis arrivé à cette conclusion :

Mon premier problème venait du fait que j’avais restreint à l’installation au groupe all_users, par habitude sans m’en rendre compte. C’est bien ce paramètre qui empêchait le fonctionnement correct de l’appli. My bad …

Et quand je l’ai remis comme avant avec visitors, all_users je suis arrivé sur mon second problème : j’ai testé sur un navigateur pas supporté.

En tout cas en réinstallant sans rien toucher et en restant sur Brave ça fonctionne. Merci à tous pour votre aide et aux gens qui maintiennent l’intégration. Je suis en train de découvrir une super appli !

[OniriCorpe]

Ah ça c’est un problème de configuration du package ynh
J’ai été voir et ça devrait être résolu à la prochaine version, qui laissera passer les requêtes de /api pour le groupe visiteurs même si le paramètre est réglé en all_users ou pour un utilisateur en particulier ^w^

Ça permet aussi d’utiliser une application mobile Home Assistant alors que l’interface Web est restreinte à un groupe ynh

Donc après la prochaine mise à jour il sera à nouveau possible de restreintre l’interface Web de HA sans avoir ce bug

Cf : Add api permission by ericgaspar · Pull Request #283 · YunoHost-Apps/homeassistant_ynh · GitHub

[ewilly]

ce n’a pas tout a fait juste car par défaut l’application est configurée en mode “visitors” (et non “all_users” et donc ne passe pas au travers de ssowat. Ainsi l’appli mobile fonctionnait et il n’y avait pas besoin de cette nouvelle autorisation.

[OniriCorpe]

si c’est ce que je dis !

en autorisation visitors : aucune restriction de /api donc pas d’erreur
en autorisation all_users (ou permissions similaires) : /api est coincé derrière le SSO de YNH, et donc il y a une erreur

avec la modification du lien que j’ai posté, peu importe dans quel groupe d’autorisation sera HA, /api sera toujours considéré comme ayant l’autorisation visitors, et donc il n’y aura plu cette erreur chiante