Serverless URL redirect avec preservation du path en HTTPS

Dans mon article précédent, nous avons vu les nouveautés apportées sur la mise en place d’un site web statique avec Hugo sur AWS via Terraform notamment celui qui héberge ce site. J’ai notamment parlé du changement du nom de domaine du site de blog.mehdilaruelle.ninja en mehdilaruelle.com qui a entraîné plusieurs défis tels que:

• Le changement de configuration de Hugo dans le config.toml (plutôt facile)
• Le certificat (plutôt facile avec l’automatisation via Terraform)
• La redirection de blog.mehdilaruelle.ninja vers mehdilaruelle.com sachant que l’hébergement du nom de domaine est situé côté OVH

Dans cet article, nous allons parler de la redirection du nom de domaine via Amazon API Gateway et AWS Certificate Manager pour le HTTPS de l’URL source. L’avantage de cette solution est qu’elle est:

• Serverless
• Permet de rewrite l’URL tout en préservant le path
• Quasiment gratuite (si ce n’est gratuit en fonction du nombre de redirection que vous allez avoir)
• Sans AWS Lambda
• Déployable avec Terraform

TL;TR: Pour ceux qui souhaitent déployer l’URL serverless redirect, voici le repository GitHub

Prérequis

Pour comprendre cet article, vous devez:

• Avoir des notions sur AWS

Pour reproduire l’exemple de ce blog, vous devez :

• Avoir un compte AWS et des credentials
• Avoir un nom de domaine
• Déployer l’infrastructure sur AWS via Terraform

Qu’est-ce qu’un path ?

Avant d’aller plus loin dans le tutoriel, il est important de bien comprendre la notion d’un path, nom de domaine, etc. Une image vaut mille mots: Source: https://velog.io/@jch9537/URI-URL

Ce que nous entendons par path préservation est donc le nom de domaine + le path. Cependant, la solution permet aussi de préserver la query string en plus du path mais pour simplifier nos explications et exemple, nous parlerons uniquement de path.

Le défi de la redirection avec OVH

Avant tout chose, il faut savoir que le nom de domaine mehdilaruelle.ninja était hébergé sur OVH quand j’ai voulu mettre en place une redirection de blog.mehdilaruelle.ninja vers mehdilaruelle.com tout en gardant le path en HTTPS.

Pour mettre en place une redirection de ce type sur OVH, le seul moyen était de passer par un serveur apache OVH. Heureusement, il était possible d’en avoir un gratuitement avec l’hébergement 100M. Une fois fait, il faut activer le SSL puis modifier la configuration du fichier .htaccess pour faire du rewrite d’URL.

Ce qui donne l’exemple suivant lorsque le serveur est prêt et configuré:

Cependant, comme dans mon cas, si vous avez un sous-domaine, il n’est pas possible de faire du multisite avec l’offre gratuite 100M et vous obtiendrez l’erreur suivante:

Pour accomplir cela, je devais souscrire à un plan supérieur afin de mettre en place une redirection. Cela me semblait être une contrainte excessive pour une opération aussi simple, ce qui m’a incité à explorer une alternative.

La solution avec Amazon API Gateway

Afin de mettre en place la redirection d’URL en mode serverless, j’ai utilisé Amazon API Gateway, qui offre la possibilité d’effectuer du rewrite d’URL (plus précisément, de la transformation) grâce à ses fonctionnalités MOCK et au Apache Velocity Template Language (VTL), le tout sans recourir à AWS Lambda.

La redirection fonctionne ainsi:

1. L’utilisateur tape l’URL (ex: https://blog.mehdilaruelle.ninja/post). Ici, on parle l’URL source.
2. Le serveur DNS qui héberge le nom de domaine source (dans mon cas OVH) redirige vers notre API Gateway. Une configuration est nécessaire sur lequel j’invite les plus curieux d’entre vous à regarder les étapes dans le repository GitHub.
3. L’API Gateway traite la requête de l’utilisateur avec le nom de domaine source. AWS Certificate Manager est utilisé pour mettre notre API Gateway en HTTPS (cela est gratuit et la vérification est plutôt simple a faire). Pour ceux qui souhaite en apprendre plus sur le sujet, la documentation officiel AWS explique les différentes étapes.
4. L’API Gateway rewrite l’URL et retourne l’URL de destination à l’utilisateur.

Ce qui nous conduit a la représentation suivante:

Vous pouvez déployer la solution avec Terraform via le repository GitHub.

Zoom sur Amazon API Gateway, MOCK et VTL

Voici une vue d’ensemble de notre API Gateway et des différentes méthodes:

Dans un premier temps, nous examinerons les méthodes d’Amazon API Gateway qui nous permettront de gérer les requêtes de nos utilisateurs, puis nous effectuerons une brève parenthèse sur le VTL.

Les méthodes d’Amazon API Gateway

Nous avons 2 méthodes:

• Un GET sur le root path ici /: Si l’utilisateur accède a notre site sans path via l’URL source (ex: https://blog.mehdilaruelle.ninja/) alors nous retournerons l’URL de destination (ex: https://mehdilaruelle.com/). Ici aucun rewrite n’est fait; nous retournons plutôt une valeur statique.
• N’importe quelle méthode (ANY) avec le path qui commence par / et de n’importe quelle valeur qui suit, représenté ici par {proxy+}: Le PROXY nous permettra de manipuler la valeur passée en path de l’URL. Cette méthode sera utilisée pour le rewrite d’URL source vers l’URL de destination en gardant le path. Pour en apprendre plus sur la ressource proxy, je vous invite à regarder la documentation d’AWS sur le sujet.

Les request et response d’Amazon API Gateway

Dans un premier temps, il faut séparer les request qui sont envoyées par notre utilisateur vers Amazon API Gateway et, d’un autre côté, les responses qui sont envoyées par Amazon API Gateway vers notre utilisateur.

Pour ceux qui ne sont pas familiers avec API Gateway, nous allons expliquer les différentes étapes:

1. Method request: Nous permet de mettre en place des autorisations sur notre Amazon API Gateway, vérifier le modèle, etc. Ici, nous n’utiliserons pas la Method request.
2. Integration request: Nous permet d’indiquer le type de service appelé (ex: AWS Lambda, Service AWS, etc) et la façon dont le service est appelé. Ici, nous utilisons un MOCK donc l’Integration request nous servira de passthrough (transmet la request telle quelle).
3. MOCK: Ne fait rien de particulier car aucun backend/service n’est appelé.
4. Integration response: C’est ici que la magie se déroule. Nous allons utiliser le Apache Velocity Template Language (VTL) dans le cas du path /{proxy+} pour récupérer la valeur du path de la request et retourner l’URL de destination avec une redirection de type HTTP 301. Cela se présente sous cette forme:
5. Method response: Ici, la méthode va ajouter la Response Header Location avec l’URL de destination.

Petite parenthèse sur le VTL

Certaines personnes pourraient être intéressées à explorer le Apache Velocity Template Language (VTL) au sein de l’API Gateway, en particulier pour ses options de transformation (sans recourir à AWS Lambda).

Le code que nous utilisons dans notre solution est le suivant:

#set($Path = $input.params().get('path').get('proxy') )
#set($context.responseOverride.header.Location = "https://mehdilaruelle.com/$Path")

Dans notre cas, au niveau de la ligne 1, nous récupérons le path transmis par la méthode /{proxy+}. Dans la seconde ligne, nous écrasons le header Location par l’URL de destination (ici: https://mehdilaruelle.com/) avec le path récupéré en ligne 1.

Pour les plus curieux, je vous invite à en apprendre plus sur la multitude de transformations possibles dans la documentation officiel d’AWS.

Conclusion

La solution que nous avons mise en place permet des redirections tout en préservant le path, de manière serverless (et pratiquement gratuite). Pour ce faire, nous exploitons la puissance d’Amazon API Gateway et du Apache Velocity Template Language (VTL), ce qui nous évite, dans notre cas, de recourir à des fonctions AWS Lambda. Il est important de noter que l’objectif ici n’est pas d’effectuer des opérations de calcul, auquel cas l’utilisation d’AWS Lambda serait nécessaire, mais plutôt de transformer la request/response.

Pour ceux qui souhaitent déployer l’URL de redirection serverless, le repository GitHub correspondant est disponible ici. Enfin, comme toujours, si vous avez d’autres idées d’améliorations, des sujets à creuser ou des retours à partager, n’hésitez pas à me contacter.