classsniper

ClassSniper est un projet d'automatisation personnelle pour réserver des cours de sport à l'instant même où leur fenêtre de réservation s'ouvre. Il cible une chaîne de salles spécifique (One Playground en Australie), dont les cours ouvrent à la réservation exactement 72 heures avant l'heure de début — une fenêtre durant laquelle les créneaux et instructeurs populaires peuvent être complets en quelques instants. Le dépôt est un modèle que vous pouvez adapter à votre propre compte et établissement. Fonctionnement - Un service cron externe appelle le point de terminaison workflow_dispatch du dépôt toutes les 60 secondes. Chaque exécution vérifie si la fenêtre de 72 heures d'une réservation en attente est ouverte. - Une fois la fenêtre ouverte, le bot réserve le cours : d'abord via un chemin API direct rapide, avec un repli vers une automatisation complète du navigateur Playwright si le chemin rapide n'est pas concluant. - Un scraper compagnon extrait le planning des cours en direct pour chaque studio selon la même cadence, afin que le tableau de bord web affiche les cours à venir réels (nom, instructeur, places restantes) plutôt qu'une simple saisie de date/heure. - Une règle de sécurité stricte bloque l'armement ou la réservation de tout cours commençant dans moins de 30 heures, car l'annulation dans les 24 heures entraîne des frais. Architecture Le dépôt sert de source de vérité via trois fichiers JSON commités (pending_booking.json, status.json, class_list.json). Un tableau de bord GitHub Pages lit ces fichiers directement — public, sans authentification requise pour la vue — et écrit les modifications d'armement/suppression via l'API GitHub Contents avec un PAT à grains fins limité au dépôt. GitHub Actions exécute l'ordonnanceur ; bot/scraper.py actualise le planning et bot/striker.py effectue la réservation. Des captures d'écran et l'état du résultat sont capturés depuis le contexte Playwright actif afin que les échecs soient enregistrés plutôt que silencieusement ignorés. Détails d'ingénierie notables - Désambiguïsation des cours : des cours distincts partagent souvent le même créneau horaire au même endroit, donc une correspondance basée uniquement sur la date et l'heure est ambiguë. Chaque cours possède un booking_id unique provenant de l'API de session de l'établissement et est apparié exactement. - Chemin rapide : la lecture du bundle JavaScript de l'établissement a révélé que le flux de l'interface utilisateur « cliquer sur Réserver → se connecter → confirmer » correspond à deux appels HTTP. Ces points de terminaison publics sont appelés directement, le flux via navigateur étant conservé comme repli testé. - Timing : le moment de l'exécution est calculé précisément, le processus s'endort jusqu'à l'instant juste avant, préchauffe sa connexion HTTP environ cinq secondes avant, puis déclenche l'action. - Choix de l'ordonnanceur : les déclencheurs de planification de GitHub Actions sont au mieux des efforts et ont été observés comme étant très espacés sous charge ; un cron externe frappant workflow_dispatch chaque minute est donc utilisé. Un groupe de concurrence et une boucle de tentative fetch-rebase gèrent les exécutions chevauchantes lors du git push. - Hygiène des identifiants : les erreurs de timeout de Playwright peuvent intégrer des valeurs DOM telles que l'e-mail de connexion. Le gestionnaire de timeout de connexion génère donc un message propre, les captures d'écran de débogage masquent les champs e-mail/mot de passe visibles, et une passe de rédaction nettoie les correspondances d'identifiants avant toute écriture dans le fichier public status.json. - Limites de débit : le chemin rapide effectue au maximum trois requêtes par tentative et ne réessaie pas, laissant du budget pour une connexion de repli. Stack et configuration Python, Playwright, GitHub Actions, et HTML/CSS/JS sans framework sur GitHub Pages. L'adaptation nécessite de forker le dépôt, d'ajouter les secrets GYM_EMAIL et GYM_PASSWORD, d'activer Pages et Actions, de fournir un jeton à grains fins pour le tableau de bord et — point important — de configurer un déclencheur externe avec un second jeton limité aux Actions, car le cron intégré est décrit comme trop peu fiable pour des frappes ponctuelles. portée Le projet automatise les propres réservations d'un seul compte personnel auprès d'un service que l'opérateur paie, en utilisant les mêmes interfaces publiques que le site web du service. Il est précisé qu'il ne contourne pas l'authentification, n'accède pas aux données d'autres membres et ne dépasse pas les limites de débit documentées. Licencié sous MIT.