Le client Vue face au serveur

L'API de la Librairie est complète : un catalogue public, des commandes vérifiées et enregistrées, un espace réservé au personnel. Mais personne ne l'utilise encore, sinon curl et nos tests. Son vrai client, c'est l'application Vue du livre précédent, qui parlait jusqu'ici au serveur d'essai serveur.mjs. Brancher l'une sur l'autre pose trois questions que ce chapitre traite dans l'ordre.

D'abord, le navigateur refuse qu'une page venue d'un site lise les réponses d'un autre site, sauf si cet autre site l'y autorise : c'est la politique de même origine, et l'autorisation s'appelle CORS. Ensuite, un client a besoin d'un mode d'emploi de l'API : nous le ferons écrire par le serveur lui-même, au format OpenAPI. Enfin, en production, il est plus simple que le serveur Java serve aussi les fichiers de l'application Vue : une seule adresse, une seule origine, et le problème du début disparaît.

Le projet code/ch9/librairie part de celui du chapitre 8. Les journaux, réponses et messages de la console du navigateur montrés ici ont été produits par ce projet, avec l'application Vue du livre précédent construite par Vite 8 et pilotée dans Chromium. Dans les réponses de curl, on n'a gardé que la ligne de statut et les en-têtes utiles au propos.

9.1 Deux programmes, deux origines

Cette règle protège l'utilisateur, pas le serveur : sans elle, une page quelconque ouverte dans un onglet pourrait lire, avec les cookies de l'utilisateur, les réponses de sa banque ouverte dans un autre. Un client qui n'est pas un navigateur (curl, un programme Java, l'application mobile) n'applique pas cette règle : CORS n'est donc pas une protection de l'API, et ne remplace en rien l'authentification du chapitre 8.

Pendant le développement, la situation est la suivante :

La page vient du serveur de développement de Vite ; l'API est ailleurs. Deux cas se présentent alors pour une requête d'une autre origine.

Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type

9.2 Autoriser des origines avec Spring Security

Les origines autorisées sont une affaire de configuration : elles changent entre le poste du développeur et la production. On les range donc dans application.yml, lues par un record, comme au chapitre 2 :

librairie:
  nom: La Librairie du Campus
  frais-campus: "2.00"
  cors:
    origines:                         # chapitre 9 : le serveur de développement de Vite
      - http://localhost:5173

/** Chapitre 9 : « librairie.cors.origines », les sites autorisés à appeler l'API. */
@ConfigurationProperties("librairie.cors")
public record CorsProperties(List<String> origines) {
}