Spécifie les règles d'authentification, d'autorisation, de limitation de débit, d'idempotence, de nouvelle tentative, de délai d'attente et d'isolation des pannes pour webSocket. Il fixe les limites d'adoption et les preuves observables d'échec tout en gardant les limites spécifiques à l'environnement configurables.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n'est faite qu'une implémentation adoptante les ait passés.
Décision
Pour WebSocket, adopter un contrat filaire versionné à la frontière du service. Appliquer le contrôle côté serveur de confiance, refuser par défaut, et définir les hypothèses de menace, les limites d'abus, les preuves et la récupération. Ce package est un contrat de référence : l'équipe adoptante doit choisir les limites numériques, les fournisseurs, les juridictions et les responsables opérationnels à partir des preuves dans son propre environnement.
Portée
- Les acteurs WebSocket, entrées, sorties, états, versions de politique ou de schéma, et résultats visibles de l'extérieur décrits par ce bloc de sécurité.
- Interfaces principales et alternatives, travaux en arrière-plan, caches, intégrations, chemins de support et preuves pouvant exercer la même frontière.
- Configuration spécifique à l'adoption, déploiement, récupération et responsabilités de vérification nécessaires pour appliquer la référence en toute sécurité.
Hors de ce bloc
- Choisir un fournisseur universel, un framework, une juridiction, un seuil numérique, une période de rétention ou un objectif de niveau de service pour chaque adoptant.
- Affirmer que les scénarios packagés ont été exécutés contre une implémentation aval ou que cette référence accorde une certification légale, de sécurité ou d'accessibilité.
Contrat
- Définir les sémantiques de requête, réponse, erreur, pagination ou événement indépendamment d'une implémentation cliente.
- Authentifier l'appelant et autoriser la ressource et l'action sur le serveur avant de retourner des données ou d'accepter un travail.
- Utiliser des délais d'attente explicites, des nouvelles tentatives bornées avec jitter, et un résultat terminal ; ne pas retenter aveuglément des effets non idempotents.
- Transporter un identifiant de corrélation à travers l'intégration tout en excluant les identifiants et charges sensibles de la télémétrie.
- Traiter tous les champs client, callback, fichier, modèle et télémétrie comme non fiables jusqu'à authentification et validation pour l'action prévue.
- Exiger une seconde sauvegarde indépendante pour les chemins à fort impact où une compromission d'un parseur, identifiant ou fournisseur serait décisive.
- Authentifier la poignée de main et l'origine le cas échéant, autoriser chaque canal et message, versionner le schéma de trame, et limiter la taille, le débit, les tampons et la durée de connexion des messages.
- Définir le heartbeat, l'ordre, les accusés de réception, la séquence reprenable, la reconnexion, la contre-pression, la livraison en double, l'expiration des identifiants et la terminaison des consommateurs lents sans perdre l'intention durable.
Guide d'implémentation
- Modéliser les menaces normales, de rejeu, d'énumération, cross-tenant, d'automatisation et de dépendance dégradée avant la revue d'implémentation.
- Modéliser les entrées, sorties, acteurs, états, invariants, effets secondaires et preuves WebSocket avant de choisir le framework ou le fournisseur.
- Stocker la version applicable du contrat ou de la politique WebSocket avec l'état matériel pour que les migrations, rejouages et décisions de support restent attribuables.
- Introduire le chemin derrière un déploiement contrôlé, comparer les résultats attendus et observés, et garder une route de récupération testée jusqu'à ce que les preuves d'adoption soient complètes.
Gestion des pannes et sauvegardes
- La défaillance d'une dépendance correspond à une erreur stable ou un état de secours ; les effets secondaires ambigus sont réconciliés avant une nouvelle tentative.
- L'état WebSocket invalide ou contradictoire est rejeté ou mis en quarantaine ; l'implémentation ne devine jamais une valeur qui élargit l'autorité ou duplique un effet.
- Les nouvelles tentatives sont bornées et utilisent une identité durable ; après épuisement, le travail atteint un état terminal inspectable avec un propriétaire responsable.
Vérification et opérations
- Utiliser des cas appariés d'autorisation et de refus à chaque frontière de confiance et confirmer que la perte de la dépendance de contrôle échoue en mode fermé.
- Surveiller le succès WebSocket, le refus, l'échec de validation, la défaillance de dépendance, l'épuisement des nouvelles tentatives et la récupération par version de contrat sans dimensions de charge sensible.
- Relancer les fixtures positives et négatives appariées après changement de politique, schéma, dépendance, migration ou frontière et conserver les preuves résultantes.
Hypothèses d'adoption
- Les noms et valeurs dans l'exemple sont un fixture concret, pas des valeurs universelles par défaut ; les adoptants les remplacent par des preuves documentées et une propriété.
- Le système adoptant peut fournir une identité authentifiée, des versions durables d'opération ou d'enregistrement, une télémétrie bornée et un chemin contrôlé pour le changement.
Les exemples à l'apparence exécutable dans ce package sont des fixtures et contrats d'acceptation. Exécutez le validateur de collection pour vérifier la structure et les métadonnées, puis traduisez et exécutez les scénarios dans le dépôt cible avant d'enregistrer les preuves d'implémentation.