Résumé

  • Le projet individuel du 28 octobre propose deux métadonnées OAuth exclusives : client_ip_ranges contient des préfixes IPv4 et IPv6 ; client_ip_ranges_uri désigne un document JSON accessible en HTTPS. Le serveur d’autorisation valide puis accepte la liste selon sa propre politique.
  • Un document introuvable, invalide ou retiré n’élargit pas automatiquement l’accès. Le serveur peut conserver l’ancien ensemble, le réduire à l’intersection d’une liste de remplacement et fixer une durée de conservation. Passé ce délai, un serveur qui applique la règle rejette les requêtes du client jusqu’à une nouvelle acceptation ou une décision locale explicite.

Le fichier arrive avant l’autorisation

Imaginez un client hébergé qui change de fournisseur de sortie réseau. Son nouveau document HTTPS est en ligne dès le matin ; l’outil de déploiement voit un HTTP 200. Pourtant la requête au point de délivrance des jetons échoue. Le texte proposé impose cette séparation : l’enregistrement de la métadonnée et la récupération du document ne valent pas acceptation de ses préfixes. Le responsable du serveur garde le droit de retenir une extension inattendue.

Le client peut mettre ses adresses dans une liste ou publier l’URL d’un document. Les deux formes ne se cumulent pas. L’absence de ces champs signifie qu’il ne déclare rien ; un tableau vide déclare un ensemble vide. C’est une différence concrète dans une mise à jour selon la RFC 7592 : le tableau vide ne demande pas la suppression du paramètre. Si le serveur applique un ensemble accepté mais vide, aucune adresse ne passe.

Une liste approuvée remplace intégralement la précédente. Le projet ne crée pas un journal d’ajouts successifs. En attendant l’approbation d’un remplacement valide, le serveur peut ne garder que l’intersection avec l’ancien ensemble : une ancienne sortie peut ainsi être fermée sans ouvrir tout de suite la nouvelle. Le client devrait déclarer une nouvelle plage avant d’y envoyer du trafic et conserver l’ancienne jusqu’à la fin réelle de son usage. Entre la publication, la prochaine récupération et la décision humaine, il peut s’écouler du temps.

Une panne du document ne fait pas sauter la barrière. Une récupération manquée ou une validation ratée ne peut autoriser une source jusque-là bloquée. Retirer sa déclaration ne détend pas davantage la règle par magie : il faut une décision locale expresse. Le serveur devrait limiter la durée de vie de l’ancien ensemble pendant une panne, un retrait ou l’attente d’un remplacement. Une fois ce délai dépassé, celui qui appliquait la restriction doit refuser les requêtes jusqu’à une liste acceptée sous la déclaration courante ou la fin explicite de cette restriction. Revérifier une proposition encore non acceptée ne remet pas le compteur à zéro.

L’ancienne liste peut aussi devenir dangereuse. Une adresse abandonnée par le client peut être réattribuée. Le serveur qui la conserve admet alors une origine dont l’ancien client n’a plus la maîtrise. L’intersection et la limite de conservation répondent à ce problème. La RFC 9111 régit le cache HTTP ; le projet distingue nettement ce cache de la liste acceptée. Un 304 Not Modified confirme un contenu mémorisé, pas son approbation politique.

Un pare-feu placé devant le service voit les IP, pas l’identité du client OAuth ; il ne peut appliquer qu’un agrégat de plages. Le serveur peut affiner le contrôle une fois le client identifié. Une IP autorisée n’est pas une authentification. Même une déclaration signée qui contient l’URL ne garantit que cette URL, pas les futures données de l’hébergeur du document. Celui-ci peut aussi bloquer le service en publiant un ensemble vide ou en laissant son fichier indisponible trop longtemps.

La fiche IETF classe le texte comme projet individuel ; elle ne donne aucun déploiement mesuré. Lors d’une migration, le fait décisif serait l’heure où la nouvelle liste a été acceptée, les adresses effectivement autorisées avant et après, et la date d’extinction de l’ancienne plage.

Sources : projet ; statut IETF ; RFC 7592 ; RFC 9111.