WAIT — Stale — last commit 3y ago

• 9 active contributors
• MIT licensed
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

An intelligent 12306 (Chinese railway) ticket scraper and auto-booker written in Python that automatically solves CAPTCHAs using local TensorFlow neural network models, logs in users, monitors ticket availability, and submits orders at optimal times. It includes features for queue-jumping (候补), email/ServerChan notifications, and supports both CLI and Docker deployment. Monolithic structure organized by function: config/ holds all configuration (email, proxy, logging, URLs), init/ handles login and ticket selection workflows, inter/ contains request wrappers for 80+ API endpoints (GetQueueCount, ConfirmSingleForQueue, etc.), agency/ manages CDN proxy rotation, verify/ handles CAPTCHA detection, and myUrllib/ wraps HTTP requests. Entry point is run.py which dispatches to r (run), c (filter CDN), or t (test notifications).

Chinese railway ticket buyers who want to automate the tedious process of refreshing 12306.cn during peak booking times; technically, Python developers familiar with web scraping, Selenium automation, and neural networks looking to understand credential-less browser automation at scale.

Actively developed but shows signs of maintenance burden: 190K+ lines of Python, Docker support present, but dependency versions are pinned to 2018–2019 era (TensorFlow 1.14, Keras 2.2.4, Selenium 3.11), no visible CI/CD pipeline in file list, and unclear recent commit activity. Suitable for personal use but requires Python 3.6–3.7 specifically; production-ready for the specific use case but not actively hardened.

Heavy reliance on outdated machine learning stack (TensorFlow 1.x, Keras 2.2.4) with no forward compatibility tested; single-author maintenance risk (repo name suggests primary owner); external CAPTCHA model dependency (12306model.git repo) must be manually downloaded and placed in root directory, adding deployment friction. 12306 (state railway ticketing) actively blocks automation, so this tool is in a security/legal gray zone and may break without notice when endpoints change.

No recent activity indicators visible in file list, but repo structure shows implemented features: asynchronous queue checking (GetQueueCountAsync.py), intelligent standby booking (ConfirmSingleForQueueAsys.py), face verification (ChechFace.py), and repeat-submission token handling (GetRepeatSubmitToken.py). Docker Compose configuration (docker-compose.yml) suggests recent infrastructure focus. No open PRs or issue data provided.

1. Clone: git clone https://github.com/testerSunshine/12306.git && cd 12306
2. Download CAPTCHA model: wget https://pan.baidu.com/s/1rS155VjweWVWIJogakechA (or clone https://github.com/testerSunshine/12306model.git) and place 12306.image.model.h5 in root
3. Install: pip3 install -i https://pypi.tuna.tsinghua.edu.cn/simple -r requirements.txt (use Tsinghua mirror for speed on mainland China)
4. Configure: Edit TickerConfig.py with credentials, email, and ticket preferences
5. Filter CDN: python3 run.py c
6. Run: python3 run.py r

Daily commands: Development mode: python3 run.py r (runs main ticket scraper with config from TickerConfig.py). Test mode: python3 run.py t (validates email and ServerChan notification config). Docker mode (recommended): docker-compose up --build -d (requires setting AUTO_CODE_TYPE=3 and HOST="captcha:80" in TickerConfig.py). Stop: docker-compose down or Ctrl+C in terminal.

• TickerConfig.py: Central configuration file for all credentials, email/notification settings, station pairs, ticket dates, and auto-code service endpoints — must be customized before any run.
• run.py: Entry point dispatcher that routes CLI commands (r/c/t) to main ticket-buying logic, CDN filtering, or notification testing.
• init/login.py: Handles Selenium-based browser automation to log into 12306.cn and establish authenticated session; critical for credential management.
• inter/GetQueueCount.py: API wrapper for polling ticket queue status in real-time; core of the intelligence that decides when to submit an order.
• inter/ConfirmSingleForQueue.py: Submits the actual ticket order request; the final step in the booking workflow that must handle race conditions and double-submission protection.
• verify/: CAPTCHA recognition module using TensorFlow neural network inference on 12306.image.model.h5; critical path for automated login.
• agency/cdn_utils.py: Rotates CDN proxy endpoints to bypass rate limiting and IP blocking; must be filtered via run.py c before use.
• config/urlConf.py: Centralized mapping of all 12306 API endpoints (query, login, booking, queue check); must be updated if 12306 changes their URLs.
• config/logger.py: Logging configuration for troubleshooting ticket booking failures; output files track queue status and API responses in real-time.

Adding a new API endpoint: Create new file in inter/ following pattern of GetQueueCount.py (HTTP method wrapper + response parsing). Changing login logic: Modify init/login.py (currently uses Selenium + CAPTCHA from verify/). Adding notification channels: Extend config/ (email in emailConf.py, ServerChan in serverchanConf.py) and import in main loop. Tuning scraping: Edit TickerConfig.py for polling interval, retry logic, and station/date filters. Testing: Add cases to UnitTest/TestAll.py (basic structure exists but sparse).

CRITICAL: Model file 12306.image.model.h5 must be manually downloaded and placed in project root — build will fail silently without it. Python version pinning: Exact versions of TensorFlow 1.14.0 and Keras 2.2.4 required; pip may auto-resolve to incompatible versions. Time sensitivity: Must run ntplib time sync (in code) to match 12306 server clock within milliseconds or orders rejected. CDN filtering required: Running python3 run.py c before first run.py r is mandatory; unfiltered CDN list will cause immediate IP bans. Config syntax: TickerConfig.py is raw Python — any syntax error halts startup without clear error message. Docker host requirement: If using Docker, AUTO_CODE_TYPE=3 and HOST="captcha:80" (internal service name, not localhost) are non-obvious; using wrong values breaks CAPTCHA solving. Rate limiting: 12306 aggressively throttles requests; too-aggressive polling intervals will trigger temporary bans. Session expiry: Selenium session management may expire mid-run; no auto-reconnect logic visible in codebase.

• CAPTCHA solving via convolutional neural networks (CNN) — This repo's core innovation is local, offline CAPTCHA recognition using a pre-trained TensorFlow/Keras model (verify/) rather than external APIs; understanding CNN architecture and inference is essential to troubleshoot or retrain the model.
• Browser automation via Selenium WebDriver — Login and user interaction is handled through Selenium (init/login.py); understanding WebDriver protocol, element locators, and wait strategies is critical for debugging authentication failures or adapting to 12306 UI changes.
• HTTP session management and cookie persistence — Authenticated API calls in inter/ require maintaining stateful sessions via cookies stored in config/getCookie.py; this project directly manipulates cookie jars to survive session expiry and parallel requests.
• CDN proxy rotation and IP spoofing — The agency/ module rotates through CDN endpoints to avoid rate limiting and IP bans; understanding proxy chains, user-agent spoofing (fake-useragent), and filtering logic is essential for evading 12306's anti-bot defenses.
• Race condition handling in distributed ticket booking — Multiple users/instances may compete for the same ticket; the async queue-checking logic (GetQueueCountAsync.py) and repeat-submission token mechanism (GetRepeatSubmitToken.py) prevent double-bookings and race losses.
• Network time protocol (NTP) synchronization — 12306 API calls require sub-second time accuracy; ntplib (in dependencies) syncs the local clock to prevent request rejection due to timestamp mismatch — critical for peak-hour booking.
• Asynchronous request queuing and polling — The ticket monitor uses async polling (inter/*Async.py files) to check queue status without blocking; this pattern prevents timeout failures during high-concurrency scenarios on 12306.

• zhaipro/easy12306 — Original CAPTCHA recognition model source mentioned in README; this repo adapted the neural network code from easy12306.
• testerSunshine/12306model — Companion model repository containing the pre-trained TensorFlow CAPTCHA recognition model (12306.image.model.h5) required by the main project.
• YinAoXiong/12306_code_server — Self-hosted cloud-based CAPTCHA-solving microservice mentioned in README; alternative to local model inference for decentralized deployment.
• seleniumpython/selenium — Upstream browser automation library (version 3.11 pinned in requirements.txt); understanding Selenium's WebDriver API is essential for debugging login failures in init/login.py.
• tensorflow/tensorflow — ML inference engine (TensorFlow 1.14 specified); knowledge of model loading and inference APIs needed to extend verify/ CAPTCHA solver.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for inter/ API modules

The UnitTest/ directory only contains TestAll.py with minimal test coverage. The inter/ directory has 20+ critical API interaction modules (Query.py, SubmitOrderRequest.py, GetQueueCount.py, etc.) that lack dedicated unit tests. This is high-risk since these modules handle ticket submission, order confirmation, and payment logic. Adding tests would catch regressions early and help new contributors understand the API contract.

• [ ] Create test files in UnitTest/ for core inter/ modules: test_query.py, test_submit_order.py, test_get_queue_count.py, test_check_order_info.py
• [ ] Add mock HTTP responses using unittest.mock or responses library to avoid hitting real 12306 APIs
• [ ] Test error handling in myException/ (PassengerUserException, balanceException, ticketNumOutException) with corresponding inter/ modules
• [ ] Add test execution to UnitTest/TestAll.py and document test coverage targets in README.md

Create GitHub Actions CI workflow for dependency compatibility testing

The requirements.txt pins old/outdated versions (requests==2.18.4, keras==2.2.4, tensorflow==1.14.0, selenium==3.11.0) that may have security vulnerabilities and compatibility issues. The README mentions windows users struggle with tensorflow versioning. A GitHub Actions workflow should test against multiple Python versions (3.6, 3.7, 3.8+) and optional dependency versions to catch breaking changes early and guide users on safe upgrade paths.

• [ ] Create .github/workflows/test-matrix.yml to run tests against Python 3.6, 3.7, 3.8, 3.9 with current and upgraded dependency versions
• [ ] Add a separate workflow file for security scanning (bandit, safety) on requirements.txt
• [ ] Document findings in a COMPATIBILITY.md file showing which dependency upgrades are safe and which versions conflict
• [ ] Reference this workflow status in README.md to help users understand tested configurations

Refactor myUrllib/ and agency/ into a cohesive HTTP client abstraction layer

Currently HTTP handling is scattered: myUrllib/httpUtils.py handles requests, agency/cdn_utils.py manages CDN proxying, and agency/proxy_list handles proxy rotation. These three concerns are tightly coupled across multiple files but lack a unified interface. This makes it hard to swap HTTP backends, test in isolation, or add new features like retry logic. Refactoring into a HttpClient class would reduce code duplication and improve maintainability.

• [ ] Create myUrllib/http_client.py with a unified HttpClient class that encapsulates httpUtils.py, cdn_utils.py, and proxy rotation logic
• [ ] Move proxy_list logic into myUrllib/proxy_manager.py with methods like get_next_proxy(), mark_proxy_dead()
• [ ] Update all inter/ modules to use HttpClient instead of calling httpUtils directly
• [ ] Add integration tests in UnitTest/test_http_client.py covering proxy rotation, CDN fallback, and timeout scenarios

• Add type hints to inter/ API wrapper modules: Files like inter/GetQueueCount.py, inter/ConfirmSingleForQueue.py lack type annotations; adding them improves IDE support and catches bugs early. Low risk, high learning value.
• Expand UnitTest/TestAll.py with integration tests for email/ServerChan notifications: config/emailConf.py and config/serverchanConf.py exist but test coverage is minimal (TestAll.py is a stub); adding tests for notification delivery would catch configuration errors before production runs.
• Create migration guide for TensorFlow 1.14 → 2.x compatibility: Dependencies pinned to TensorFlow 1.14 (2018 era); creating a doc or branch showing how to upgrade verify/ CAPTCHA inference to TensorFlow 2.x would future-proof the project and help users avoid legacy version issues.
• Document agency/cdn_utils.py filtering logic with examples: run.py c (CDN filtering) is mentioned as 'very important' in README but filter_cdn_list logic is opaque; adding inline comments and a usage example in README.md would reduce user confusion and fork-and-tweak cycles.

• Critical · Severely Outdated and Vulnerable Dependencies — requirements.txt, requirements-docker37.txt. The project uses extremely outdated dependencies with known critical vulnerabilities. requests==2.18.4 (released 2018) has CVE-2018-18074 (header injection), selenium==3.11.0 has multiple vulnerabilities, tensorflow==1.14.0 (2019) has known RCE vulnerabilities, and keras==2.2.4 has deserialization issues. These versions are 5+ years old and unmaintained. Fix: Update all dependencies to latest stable versions: requests>=2.31.0, selenium>=4.15.0, tensorflow>=2.13.0, keras>=3.0.0. Run 'pip-audit' or 'safety check' to identify remaining vulnerabilities.
• Critical · Python 2.7 End of Life — Dockerfile. Dockerfile uses Python 2.7.15, which reached end-of-life on January 1, 2020. No security patches are available. This creates an unmaintainable and inherently vulnerable runtime environment. Fix: Migrate to Python 3.11+ immediately. Update Dockerfile: FROM python:3.11-slim instead of python:2.7.15. Update all code to Python 3 syntax.
• High · Potential Credential Exposure in Configuration Files — config/emailConf.py, config/pushbearConf.py, config/serverchanConf.py, config/getCookie.py. Multiple configuration files exist (emailConf.py, pushbearConf.py, serverchanConf.py, getCookie.py) that likely contain API keys, passwords, and authentication tokens. If these files contain hardcoded secrets, they would be exposed in the Docker image and version control. Fix: Never commit credentials to version control. Use environment variables for all secrets. Implement a secrets management system. Add *.key, *.pem, *.json (for credentials) to .gitignore. Review git history for exposed secrets with 'git-secrets' or 'truffleHog'.
• High · Insecure HTTP Requests Without Verification — myUrllib/httpUtils.py, myUrllib/MySocketUtils.py. The myUrllib/httpUtils.py module makes HTTP requests likely without certificate verification or timeout protections. Combined with outdated requests library, this enables MITM attacks and request hijacking. Fix: Enable SSL/TLS verification (verify=True by default), set reasonable timeouts (timeout=30), implement certificate pinning for sensitive endpoints, use Session objects with retry logic.
• High · Machine Learning Model Trust Issue — 12306.image.model.h5, model.v2.0.h5, verify/mlearn_for_image.py. The project downloads and loads pre-trained ML models (12306.image.model.h5, model.v2.0.h5) from external sources (Baidu Pan, GitHub) without integrity verification or signature validation. These could be poisoned/backdoored models. Fix: Verify model integrity with cryptographic checksums (SHA-256). Host models on trusted infrastructure. Implement model signature verification. Audit model source code. Consider sandboxing model execution.
• High · Insecure Deserialization Risk — verify/mlearn_for_image.py, verify/pretreatment.py. Keras and older TensorFlow versions use pickle-based serialization (h5 files) which are inherently unsafe. Untrusted model files can execute arbitrary code during loading. Fix: Use safer serialization formats (SavedModel format in TF2+). Never load models from untrusted sources. Implement strict input validation and sandboxing.
• Medium · Missing Input Validation — inter/*, init/*, config/TicketEnmu.py. File structure suggests parsing user input (train schedules, passenger info, payment data) without visible validation layers. Risk of injection attacks, buffer overflows, and logic bypasses. Fix: Implement comprehensive input validation: whitelist allowed characters, validate lengths, use parameterized queries, sanitize all external input. Use a validation library like 'pydantic' or 'voluptuous'.
• Medium · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/testerSunshine/12306 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live testerSunshine/12306 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/testerSunshine/12306.

What it runs against: a local clone of testerSunshine/12306 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in testerSunshine/12306 | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 1163 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of testerSunshine/12306. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/testerSunshine/12306.git
#   cd 12306
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of testerSunshine/12306 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "testerSunshine/12306(\\.git)?\\b" \\
  && ok "origin remote is testerSunshine/12306" \\
  || miss "origin remote is not testerSunshine/12306 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1163 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1133d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/testerSunshine/12306"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.