Ouvrez votre réseau aux écrans LobbyFlight

Ouvrez votre réseau aux écrans LobbyFlight

Cet article s'adresse à la personne qui gère le réseau de l'hôtel. Il vous dit précisément quels hôtes un écran LobbyFlight contacte, à quelle fréquence il le fait, et quelles règles de pare-feu bien intentionnées cassent le tableau d'une manière difficile à reconnaître comme un problème réseau.

Ce que vous laissez réellement passer

Un écran LobbyFlight n'est ni un boîtier ni un agent. C'est un navigateur posé sur une page web — /display/<hotelId> — qui récupère des données en HTTPS et en dessine un tableau des vols. Tout ce qu'il fait, c'est une requête sortante de ce navigateur vers un serveur web.

Deux conséquences en découlent, et ce sont justement les deux points sur lesquels les services informatiques posent le plus de questions. Vous n'avez aucun port entrant à ouvrir, puisque rien ne se connecte jamais *vers* l'écran. Et vous n'avez pas besoin d'autoriser les WebSockets, puisque le produit n'en utilise aucun : le tableau interroge le serveur par minuterie plutôt que de maintenir une socket ouverte. Si votre supervision signale une connexion de longue durée sur le port 443 depuis un écran, ce n'est pas nous.

Vous n'avez pas non plus besoin de VPN, de tunnel ni d'un quelconque protocole au-delà du simple HTTPS.

Les hôtes à autoriser

Autorisez le HTTPS sortant vers lobbyflight.com et *.lobbyflight.com. Cela couvre la page de l'écran elle-même, le point de terminaison de configuration, les données de vols, le point de terminaison météo et le battement de cœur : tout est servi depuis l'origine du produit.

Si votre hôtel est sur le plan Premium et utilise Portal → Marque Blanche → Domaine Personnalisé pour diffuser le tableau sous votre propre nom d'hôte, par exemple flights.votrehotel.com, ce nom d'hôte doit lui aussi figurer dans la liste d'autorisation. C'est de loin la raison la plus fréquente pour laquelle une règle de pare-feu qui semble correcte laisse malgré tout un écran noir : une règle pour *.lobbyflight.com ne s'applique pas à un écran servi depuis votre propre domaine.

Au-delà des domaines du produit, le navigateur de l'écran s'adresse à un petit nombre d'hôtes tiers :

Deux hôtes que d'anciennes versions de cet article mentionnaient n'existent pas et n'ont rien à faire dans vos règles : il n'y a ni api.lobbyflight.com ni cdn.lobbyflight.com. L'API publique se trouve à l'adresse https://lobbyflight.com/api/v1. Les images téléversées — logo de l'hôtel, logo de l'écran, diapositives d'information — sont servies depuis l'origine du produit sous /_next/image, il n'y a donc aucun hôte CDN distinct à ouvrir. Google Fonts n'est pas nécessaire non plus : les polices de l'écran sont compilées au moment du build et servies depuis notre propre domaine, et la Content-Security-Policy du site fixe font-src 'self' data:, si bien qu'une requête vers fonts.googleapis.com ne serait même pas émise.

Ports

Le port 80 compte moins longtemps qu'on ne le croit. Le site envoie Strict-Transport-Security avec un max-age de deux ans, includeSubDomains et preload : après le premier contact réussi, le navigateur bascule de lui-même en HTTPS et ne redemande plus jamais le port 80. Tout ce qui rétrograde le trafic en HTTP simple échouera au lieu de servir de solution de repli.

À quelle fréquence l'écran parle

C'est la partie sur laquelle un service informatique peut réellement s'appuyer pour planifier, voici donc le vrai profil de requêtes d'un écran :

Le navigateur met les images en cache de façon agressive : logos, images de diapositives, icônes et polices sont servis avec un en-tête de cache d'un an et immuable, ils sont donc récupérés une seule fois. Notez qu'il s'agit d'un cache HTTP ordinaire. Aucun service worker n'est enregistré sur la route de l'écran, il n'y a donc aucun tampon hors ligne derrière ; quand le réseau disparaît, les requêtes ci-dessus échouent simplement jusqu'à son retour.

La règle qui casse la chose la moins visible

Si votre liste d'autorisation est trop étroite et que seul le battement de cœur est bloqué, rien ne semble aller de travers. L'écran continue d'afficher des vols, les clients voient un tableau qui fonctionne et personne dans le hall ne remarque quoi que ce soit. Mais le portail n'a plus de nouvelles de l'écran et, au bout de 12 minutes, il l'affiche comme Hors ligne.

Ce seuil est délibéré. L'écran envoie un battement toutes les 5 minutes ; une fenêtre de 12 minutes correspond donc à deux battements manqués plus un peu de marge — assez large pour qu'un rechargement ou une brève coupure ne déclenche pas de fausse alerte. Si un écran affiche un statut que vous n'arrivez pas à concilier avec ce que vous voyez dans le hall, vérifiez que /api/analytics/heartbeat est joignable avant d'aller inspecter l'écran lui-même.

Proxys et inspection SSL

L'écran est un navigateur : un proxy explicite configuré dans ce navigateur sera donc utilisé. Ce que vous ne pouvez pas présumer, c'est qu'un proxy soit inoffensif.

Le site applique une Content-Security-Policy stricte : default-src 'self', font-src 'self' data:, et des listes fermées pour img-src et connect-src. Tout ce qui s'intercale et réécrit le HTML, injecte un script ou sert du contenu depuis un hôte absent de ces listes est bloqué par le navigateur lui-même, quoi qu'autorise votre pare-feu. Un proxy qui se contente de relayer des octets ne pose pas de problème. Un proxy qui les modifie, si.

Il en va de même pour l'inspection SSL. Mettez les hôtes dont l'écran a besoin sur la liste de contournement de l'inspection — lobbyflight.com, *.lobbyflight.com, votre propre domaine en marque blanche si vous en utilisez un, et openweathermap.org. Il n'y a aucun certificat LobbyFlight à importer ; les certificats sont émis par la plateforme d'hébergement, contourner l'inspection pour ces hôtes est donc la seule option. Si vous laissez l'inspection active et que le battement de cœur fait partie des victimes, vous obtenez exactement le cas silencieux « hors ligne » décrit plus haut.

Les clients passent par un second chemin

Les écrans ne sont pas le seul trafic LobbyFlight de l'établissement. Si votre hôtel utilise le compagnon client, les clients scannent un QR code et ouvrent /guest/<token> sur leur propre téléphone — une petite application web progressive qui enregistre un service worker pour l'espace client. Ce trafic vient du wifi clients, pas du VLAN des écrans, et il va vers les mêmes domaines. Un jeu de règles qui verrouille le VLAN d'affichage ne l'affecte pas, mais un portail captif ou un filtre sur le réseau clients, si.

Vérifier que tout fonctionne

Depuis le segment réseau de l'écran, interrogez le point de terminaison de santé et attendez un 200 OK :

curl -s -o /dev/null -w "%{http_code}\n" https://lobbyflight.com/api/health

Ajouter ?detailed=true renvoie un détail par service au lieu d'un statut global unique, ce qui est plus utile quand quelque chose n'est cassé qu'en partie. Il existe aussi https://lobbyflight.com/api/status. Faites pointer votre supervision sur ces adresses, sur le domaine principal : une vérification contre api.lobbyflight.com échouera indéfiniment, car cet hôte n'existe pas.

Si un écran ne démarre toujours pas une fois les règles en place, procédez dans cet ordre : vérifiez que le DNS résout bien l'hôte que l'écran utilise réellement (votre domaine en marque blanche, si vous en avez un), vérifiez que le port 443 est ouvert vers lui, puis désactivez l'inspection SSL pour cet hôte et réessayez.

Quand vous avez besoin de nous

Écrivez à info@lobbyflight.com avec pour objet Configuration IT/Réseau et joignez vos règles de pare-feu ainsi que tout message d'erreur dont vous disposez. Nous indiquer l'identifiant de l'écran et si le portail l'affiche en ligne ou hors ligne évite un aller-retour, car cela nous dit immédiatement si le battement de cœur passe.

Étapes suivantes