Les redirections sont faciles, n’est-ce pas ?

Rien ne semble plus facile que de rediriger une requête web vers une autre page – il suffit d’envoyer un HTTP 302 et le tour est joué ! Eh bien, … ce n’est malheureusement pas le cas dans le monde des portails captifs. Regardons de plus près regardons de plus près les redirections.

Pourquoi voulons-nous rediriger les utilisateurs ?

Un nombre croissant d’opérateurs WiFi souhaitent rediriger les utilisateurs vers un site web arbitraire avant ou après la connexion. Il existe de nombreux cas d’utilisation où les redirections sont effectuées vers des sites web de

• les hôtels avec des informations sur le petit-déjeuner, les offres spéciales, le bien-être …
• restaurants, cafés ou pubs proposant leur menu
• des portails d’hôtes (de tiers) offrant des informations sur les activités possibles pour les hôtes dans la région
• les événements auxquels les visiteurs assistent actuellement, afin d’afficher l’emploi du temps
• tout site web souhaitant afficher des publicités avant d’autoriser l’ouverture d’une session
• …

Quand réorienter

L’opérateur d’un portail captif a deux possibilités pour rediriger un client :

1. soit prendre un client en ligne d’abord et le rediriger ensuite vers le site web externe
2. soit rediriger le client hors ligne exclusivement vers un site web particulier.

Ces deux méthodes posent des problèmes réels auxquels tout portail captif doit faire face aujourd’hui.

1. Redirection après la connexion (ou pas de connexion du tout)

Examinons d’abord la version la plus courante des redirections. L’invité s’est connecté au réseau par une méthode quelconque (mot de passe, login facebook, …) et est maintenant autorisé à accéder à l’internet. Le portail captif envoie maintenant une redirection (HTTP 302). Tout le monde s’attend à ce que cette page s’affiche maintenant … mais attendez … où est passé mon navigateur ? Sur de nombreux appareils mobiles, le navigateur captif se ferme juste après la vérification de la connectivité. C’est le cas de millions d’appareils Android. Les appareils Apple iOS gardent leur navigateur captif ouvert et proposent un bouton « Terminé ». Cela rend les redirections après la connexion pratiquement inutiles sur plus de 50 % des appareils Android. /en/blog/closing-the-protocol-gap/

Pour en savoir plus sur les contrôles de connectivité, consultez notre article de blog intitulé The protocol gap of Captive Protals.

2. Redirection avant la connexion

La redirection avant la connexion n’est pas prise en charge par tous les portails captifs, car elle est beaucoup plus compliquée à mettre en place. Pour y faire face, le système doit offrir une fonction dite de « jardin clos » permettant à un client d’accéder à un certain site web, mais pas à d’autres. Sur IACBOX, nous appelons cette fonction « pages libres d’utilisation ». Autrefois, un site web était entièrement autonome et tous les fichiers étaient servis en clair à partir d’un serveur web sous un domaine. S’il est facile d’établir une liste blanche pour un domaine, de nos jours, un site web typique est servi sous forme cryptée, a un contenu très dynamique et contient de nombreuses références externes telles que

• Widgets de plates-formes sociales (par exemple, bouton « j’aime » sur Facebook, flux Twitter, …)
• Fichiers statiques comme les polices, les images
• Services d’analyse/de suivi comme google analytics
• Services de publicité
• Et bien d’autres encore

Cela entraîne les problèmes suivants :

• Les grandes plateformes comme Google, Facebook, etc. ont un nombre infini de serveurs qui répondent aux demandes sur le même domaine. Par exemple, une entrée DNS pour www.googleanalytics.com a une durée de vie très courte d’à peine 3 minutes avant qu’une autre adresse IP ne soit fournie. De nombreuses fermes de serveurs fournissent également plus d’une adresse IP par domaine et le client choisit l’une d’entre elles (round-robin). Cela signifie que nous devons garantir un accès libre à une tonne d’adresses IP et que celles-ci doivent être mises à jour très souvent.
• Les pages web à fort trafic diffusent leur contenu sur des réseaux de diffusion de contenu (CDN) pour des raisons de performance, avec les mêmes caractéristiques que celles décrites ci-dessus.
• La liste blanche des domaines est facile à établir pour le trafic non crypté, mais comme de plus en plus de pages web sont servies cryptées via HTTPS, nous devons traiter avec des IP plutôt qu’avec des domaines. Un proxy transparent pour le trafic TLS peut causer des problèmes pour le trafic non web.
• En donnant accès à d’immenses plateformes (Google, Facebook, Amazon Cloud, …), on rend de grandes parties de l’internet accessibles pour le simple fait d’avoir un site web entièrement fonctionnel.
• Le contenu dynamique provenant de plateformes tierces pose également un problème supplémentaire : un jardin clos doit disposer d’une résolution dynamique des liens externes, ce qui n’est pas une tâche facile à l’ère des pages web Javascript générées à la volée.

Comme vous pouvez le constater, l’aménagement d’un jardin clos est quelque chose d’assez flou – rien que l’on puisse qualifier de fonctionnalité solide comme le roc.

Des attentes erronées

Nous voyons de plus en plus de clients finaux qui se demandent pourquoi les redirections ne fonctionnent pas comme prévu. On ne peut pas vraiment blâmer les personnes qui n’ont pas de connaissances techniques pour avoir des attentes erronées. Nous sommes un peu surpris que même les entreprises qui fournissent des sites web de redirection vendent parfois leurs plateformes aux clients en promettant que « notre page s’affiche juste après que l’invité se soit connecté au réseau » et que « cela fonctionne avec presque tous les routeurs existants ». La réalité est différente, du moins avec les appareils Android, et aucun d’entre nous ne peut changer ce comportement.

Des solutions ?

Les opérateurs de portails captifs doivent faire face à l’état actuel d’une redirection qui ne fonctionne probablement que sur les appareils iOS et les ordinateurs portables. Et pour les autres, la seule solution est de distribuer un document à l’arrivée à l’hôtel. IACBOX prend également en charge la tâche complexe de servir des pages en mode hors ligne via notre jardin clos libre d’utilisation pour une redirection avant connexion, mais cela dépend principalement du site web lui-même si un accès stable peut être fourni à toutes ses dépendances externes.

Actuellement, il n’y a pas d’autre option, nous devons examiner chaque page de redirection séparément et décider quelle est la meilleure solution pour ce cas particulier.