Réponse rapide
Ce guide relie une véritable requête de test de Telegram au code exécuté localement. Publication uniquement après test dans un sandbox maîtrisé, vérification des sources officielles actuelles et attribution d’un responsable de maintenance.
Étapes
- Préparer un sandbox ou compte de test, le type d’événement, le secret et un handler local minimal.
- Démarrer le handler et vérifier une route de santé déterministe.
- Installer/se connecter à Oxaa, exécuter
oxaa http <port>et attendre edge-ready. - Copier l’URL HTTPS et le chemin exacts dans le réglage fournisseur actuel.
- Déclencher un véritable événement de test.
- Confirmer livraison fournisseur, métadonnées Oxaa et réponse du handler local.
- Vérifier body brut/signature, timestamp, retry et proxy approuvé.
- Activer la capture locale limitée uniquement si nécessaire ; masquer et supprimer les données sensibles.
- Utiliser le replay Oxaa seulement pour les requêtes éligibles ; demander une nouvelle livraison fournisseur si timestamp ou token doit être frais.
- Supprimer callback, faire tourner le secret, supprimer les captures et transférer la production vers l’endpoint déployé ou la plateforme d’événements.
Verification spécifique à Telegram
Configurez le webhook ou callback Telegram actuel avec l’URL et le chemin Oxaa exacts. Déclenchez un véritable événement de test et vérifiez l’enregistrement de livraison du fournisseur, les métadonnées Oxaa et la réponse de l’application locale. Le guide de production doit valider setWebhook, secret token lorsqu’il est pris en charge et getWebhookInfo.
Traitement du trafic et des données de l’Inspector
L’edge public d’Oxaa termine le TLS public afin de résoudre le nom d’hôte exact, d’identifier la route authentifiée en cours et de transférer la requête. La session entre l’appareil enrôlé et Oxaa est chiffrée ; elle remet la requête uniquement au service local sélectionné.
Oxaa conserve des métadonnées limitées de compte, route, usage, sécurité, facturation, support et diagnostic nécessaires au fonctionnement et à la protection du service. La capture de body dans l’Inspector est une action de débogage distincte et explicite : la copie limitée du body de la requête ou de la réponse affichée dans l’Inspector local reste sur l’appareil du développeur et peut être masquée, supprimée immédiatement ou expirer automatiquement. Le trafic public doit néanmoins être traité par l’edge ; la formulation exacte est donc « copies de l’Inspector conservées localement », et non « Oxaa ne peut pas voir le trafic ».
Dépannage
Commencez par vérifier le processus local, le port et le schéma. Contrôlez ensuite l’authentification et l’horloge, DNS, UDP/443, le fallback TCP/443, le proxy d’entreprise ou l’interception TLS, la propriété de la route et l’état edge-ready. Utilisez oxaa routes list, oxaa diagnose --network et des identifiants d’erreur stables ; relisez les diagnostics avant partage et retirez les secrets, bodies et chemins privés.
Nettoyage et passage en production
Supprimez le callback externe, l’URL de prévisualisation ou l’association DNS ; faites tourner les identifiants de test ; supprimez les captures locales ; arrêtez la route ; puis révoquez l’appareil ou la session si nécessaire. Le trafic de production doit être confié à l’application déployée, à un ingress de production ou à une plateforme de livraison d’événements adaptée.
Ce qu’Oxaa est - et ce qu’il n’est pas
Oxaa fournit une connectivité de développement vers un service HTTP ou HTTPS local sélectionné tant que l’appareil enrôlé et la route authentifiée restent actifs. Ce n’est ni un hébergement applicatif, ni un VPN généraliste, ni un forward proxy, ni un déploiement permanent de production, ni un tunnel raw TCP/UDP, ni un passthrough TLS arbitraire, ni un substitut de CDN/WAF, ni une plateforme de livraison de webhooks de production.