Hello,
Pour information et pour éviter les doublons je devrai lancer demain Claude sur une intégration Daikin
La vidéo sur le développement d’une intégration externe m’a fortement donné envie de me lancer
J’aurai également peut être besoin de testeur
Je vous tiens au courant
C’est developpé et dispo uniquement pour les tests pour le moment :
Build and publish image #1
Par contre je vais attendre la prochaine version pour la sortie de cette PR afin de tester l’authentification:
master ← claude/spotify-https-integration-jv3xnp
ouvert 05:34PM - 03 Aug 26 UTC
### Description
OAuth2 providers now require an HTTPS redirect URI. Spotify [en… forces it since April 2025](https://developer.spotify.com/documentation/web-api/concepts/redirect_uri): only `https://` is accepted, plus the loopback literals `http://127.0.0.1:PORT` and `http://[::1]:PORT` — `localhost` is refused, and so is any LAN address.
The frontend built `redirect_uri` from `window.location.origin`, so anyone reaching Gladys at `http://192.168.1.50:1443` — most self-hosted users — got `redirect_uri: Not matching configuration` and simply could not connect a Spotify account.
`redirect_uri` is now the fixed HTTPS page `https://my.gladysassistant.com/redirect/oauth` (static site, source in [GladysAssistant/my.gladysassistant.com](https://github.com/GladysAssistant/my.gladysassistant.com)). The address to come back to travels in the OAuth2 `state`, the only parameter a provider hands back untouched:
```js
state = base64url(JSON.stringify({ v: 1, origin, path, state: '<the integration state>' }));
```
The redirect page unwraps it, shows the visitor which instance they are about to return to, and bounces them there with every provider parameter forwarded. Nothing runs server-side there: no authorization code, token or credential ever reaches a Gladys server. It only redirects to an HTTPS origin or to a plain-HTTP origin that can exist solely on the visitor's own network, always behind an explicit click.
This is the same approach Home Assistant takes with `my.home-assistant.io`.
**Integrations need no change.** They already receive the `redirect_uri` and use it as-is (`onOAuthAuthorizeUrl(key, redirectUri)`), and they get their own `state` back to verify. The server is untouched too — the whole change is in the frontend.
Also in this PR:
- the configuration screen now **shows the redirect URI to copy** into the provider's developer application, with a copy button. Guessing it wrong is what people were stuck on in the forum thread.
- users who already serve Gladys over HTTPS can **opt out** and use their own address instead (offered only when the frontend is served over HTTPS, remembered in `localStorage`).
- the `redirect_uri` used is stored alongside the oauth2 key so the callback sends back exactly the same one — the provider compares it byte for byte at token exchange.
**One behaviour change for integration authors**: the `state` becomes mandatory in the authorize URL. Without it there is no way home, so an integration that omits it now gets an explicit error message instead of failing silently. `docs/specs/external-integrations.md` is updated accordingly.
A side benefit worth knowing: a single URL now has to be declared at the provider, whether the user reaches Gladys locally or through Gladys Plus. Before, the redirect URI depended on how you were browsing.
## Forum
Forum: https://community.gladysassistant.com/t/impossible-de-creer-le-plugin-spotify/10439
### Checklist
- [ ] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed
- [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [x] No undocumented breaking change
On the first box, being explicit about what was and was not run:
- No server code changed, so the server suite is untouched by this PR.
- Cypress was not run — it needs a live Gladys stack with an installed external integration.
- `npm run build`, `npm run eslint` (0 errors), `npm run prettier-check` and `npm run compare-translations` all pass on the front.
- The wrapping was verified end to end against the redirect page: a realistic Spotify authorize URL goes through `wrapAuthorizeUrl()`, then through the page's `decodeWrappedState()` / `buildRedirectUrl()`, and comes back as `http://192.168.1.50:1443/dashboard/.../oauth-callback?code=…&state=<the integration state>` with `client_id`, `scope` and `redirect_uri` untouched. The redirect page itself has 15 unit tests covering the origin and path checks.
- The front has no unit test runner today, so `front/src/utils/oauth.js` ships without tests. Happy to add one if you want a runner introduced.
---
_Generated by [Claude Code](https://claude.ai/code/session_0197FhTmFSecAUY5CqCYG7vN)_
## Summary by CodeRabbit
- **New Features**
- Added copyable HTTPS redirect URIs for OAuth setup.
- Added support for instance-specific redirect addresses when available, with a user-selectable option.
- Improved OAuth callback handling with stronger security-state validation.
- Added clearer connection guidance and invalid-state error messages.
- Added English, German, and French localization updates.
- **Documentation**
- Expanded OAuth guidance covering redirect setup, local HTTP instances, callback routing, and token handling.
@pierre-gilles Une idée de quand sort la prochaine version avec le redirect page ?
Merci
J’essaie de faire ça ce soir
C’est live dans la 4.84.4 :
Salut à tous !
Petite release du soir, suite directe aux retours d’hier : le vrai fix OAuth Spotify (via HTTPS), le bug d’alarme pendant l’armement, et quelques améliorations UX bien concrètes my.gladysassistant.com
Spotify (et les providers OAuth modernes en général) n’acceptent plus une redirect_uri en HTTP sur une IP locale (http://192.168.x.x). Résultat : la plupart des installs auto-hébergées se prenaient un redirect_uri: Not matching configura…
Merci
L’Oauth2 fonctionne bien et j’ai pu effectuer des tests
L’intégration est prête
@prohand
Pour mon. information perso, quel sont les appareil daikin qui serait compatible avec cette intégration ?
Les climatiseurs seront compatible
Tu peux voir le readme ici :
Gladys external integration to connect daikin cloud in Gladys Assistant
actuellement aucun ahah
Attention ici on traite que les climatiseurs qui sont connectés sur le cloud daikin et qui utilise l’application onecta
Petite fix car les valeurs n’étaient pas raffraichit après la 1er connexion au cloud :
Sur une première installation, l’ordre est : le conteneur se connecte à Gladys avant que le compte Daikin n’existe. Le handler connected (index.js:241) détecte !api.isConnected, affiche « aucun compte lié » et retourne — il n’atteint jamais l’étape 4, startPolling().
Ensuite l’utilisateur fait l’OAuth : onOAuthCallback faisait une lecture unique (refreshAndPublish) pour peupler l’écran Découverte… et rien de plus. Le timer n’était donc jamais armé. Les seules façons de le démarrer étaient un redémarrage du conteneur, ou un changement de l’intervalle dans la config (seul cas où onConfigUpdated appelait startPolling()).
D’où le symptôme exact : premières valeurs correctes, puis plus aucun rafraîchissement toutes les 900 s.
Version 1.0.7 dispo
Super ton intégration et merci. J’ai une remarque. Je trouve ton logo/icône beaucoup trop générique. Je rajouterai la marque ou le protocole dessus. Ce sera plus explicite.
Dispo dans la prochaine version qui devrait être dispo dans l’heure :
Attention à bien vider vos cache si jamais vous voyez pas la bonne image après la mise à jour
Je voulais avoir votre avis concernant une fonctionnalité que j’ai commencé à faire développer par claude mais qui implique une contre-partie dans le suivi de l’energie.
En gros j’ai vu que dans la partie suivi de l’energie ceci était apparu :
Ceci était également au niveau 0 à la base mais vous comprendre mieux un peu plus tard
Je me suis dis qu’on allais exploiter la partie Suivi de l’energie de Gladys avec ces informations qui remontent dans Gladys :
Je lui ai demandé donc de me créer 2 fonctionnalités qui sont « Consommations 30 minutes » et Coût 30 minutes"
Et après l’avoir testé sur la journée du 08/08 la valeur de consommation correspond exactement à ce que j’ai dans l’application Daikin (Idem pour le 09/09) :
Le petit hic c’est que dans le suivi de l’energie on a « Énergie ce mois-ci » et « Énergie cette année » qui reste au niveau 0 de l’intégration comme l’indique la doc ici :
# Daikin Cloud
Pilotez vos climatiseurs Daikin depuis Gladys, via **l'API cloud officielle
Daikin Onecta** — le même cloud que celui utilisé par l'application mobile
Onecta. Aucun matériel à ajouter, aucun bricolage : vos unités continuent de
fonctionner exactement comme aujourd'hui, Gladys devient simplement une
télécommande de plus.
## Ce que vous obtenez
Pour chaque climatiseur de votre compte Daikin, Gladys crée un appareil avec les
fonctionnalités que votre modèle prend réellement en charge :
| Fonctionnalité | Rôle |
| ---------------------------------- | ------------------------------------------------------------------------------- |
| Marche/Arrêt | Allumer et éteindre l'unité |
| Mode | Auto, Froid, Chaud, Déshumidification, Ventilation seule |
| Température de consigne | La consigne du mode actuellement actif |
| Vitesse (niveau) | La vitesse de ventilation, sur l'échelle déclarée par votre unité (souvent 1-5) |
| Balayage horizontal | Le sens du flux d'air gauche/droite |
afficher l'original
En gros cela ressemble à ceci :
Pour vous je peux pousser en prod cette version avec la conso et le coût 30 minutes ou bien il y a des choses à revoir ?
Merci
