chaoxing-sign-app is a third-party client for a Chinese course platform

A wrapper around a decompiled mobile client

The project describes itself as a third-party version of the Chaoxing learning platform, and the repository layout says exactly how that is achieved. There is a `decompiled/` directory at the top level, the project points to a write-up on simulating the platform's Android client, and the acknowledgements say the implementation was based on two earlier projects, a command line sign-in tool and a sign-in user interface. The technology stack is TypeScript, built with uni-app, with the newer version moving to Electron, Next.js and Node.js on desktop and web, and Capacitor on mobile, targeting Linux, Windows, macOS, iPad, iPhone, Android and HarmonyOS. The package manifest is small, with husky for git hooks and commitlint for conventional commits, and the main build lives under `projects/`. The approach has an obvious consequence that is worth stating plainly: the app talks to the platform the way the original Android client does, so it inherits whatever the platform does and does not allow.

The sign-in methods are the feature list

The project enumerates the check-in types it supports, and the list is the product. Ordinary sign-in is included, with the documentation noting in passing that there is no real need for this program for that one. Photo sign-in lets you pick any image from the phone, and a plain sign-in can be used instead, in which case no image is uploaded but the sign-in still succeeds, with the teacher's side showing that there is no picture. Location sign-in lets you pick the place on the map that pops up. Gesture sign-in works without knowing the gesture, and the check-in code variant works without knowing the code. QR code sign-in ignores the ten second window, and you can do it by scanning, by choosing a QR code file, by typing the QR content, or by typing the enc parameter. There is also support for multiple accounts, so you can switch between them. What is not in the list is automation: the documentation states clearly that only manual sign-in is possible, and automatic sign-in may be added later depending on the situation.

What the course and activity screens do

The user flow has three parts. The course list shows every course in the root directory, and the documentation warns that it may lag or stutter when there are many courses, suggesting that you move finished courses into a folder to keep it responsive, and tapping a course icon jumps to the corresponding activity page for that course. The activity screen has tabs, and the course tab is sorted the way the platform itself sorts, with unfinished activities first and then by start time descending. The second tab is the sign-in method, and the documentation notes that clicking the row containing the sign-in icon triggers the operation. The third is the sign-in type, where the behaviour depends on the method the course requires. The last section, the profile page, is the weakest part of the implementation, because the information shown there is extracted by regular expression matching against the HTML the platform returns, and the documentation is candid that the platform's HTML appears to have been modified in some way, so the regular expression sometimes matches and sometimes does not.

Deployment shape and the map key requirement

The current version supports Docker server deployment, and it can optionally run as a termux or magisk module. The development notes list three things you have to arrange before it will work. The crypto-js package is installed with `npm i crypto-js`. The uni-app application identifier needs to be obtained again, which is the step that usually catches a new developer, since the identifier ties the build to a registered application. And the map is provided by Amap, so you need to configure your own app key, with the project pointing at the DCloud Q and A page for the map plugin configuration. The package manifest reflects a small tooling surface.

  "name": "chaoxing-sign-app",
  "private": true,
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "prepare": "husky"
  },

The test script is the npm placeholder, so there is no test suite, and the `prepare` script installs the husky hooks. There is a `pnpm-workspace.yaml` and a `pnpm-lock.yaml`, so the workspace uses pnpm.

What the project itself says about using it

The declaration section is unusually explicit and it is part of the project, not a footnote. The project is based on the GPL-3.0 licence, fully open source and free, and is intended only for technical study and exchange. The developers state that they have not authorised any organisation, institution or individual to use it for commercial or profit-making activities, that they have never used it for profit-making purposes, and that they will not do so in future. They also state that any disputes or legal problems arising from use of the project are borne by the user, that starting to use the project constitutes agreement to the terms of the disclaimer, that updates to the terms will not be notified separately, and that anyone who encounters a violation of the relevant platform rules is asked to contact them for removal. For a project that automates interaction with somebody else's learning platform, that is the part of the documentation to read carefully, because it is telling you both what the maintainers accept and what a platform operator is likely to think.

The alternatives table is the honest comparison

The README lists other projects in the same space, and reading it is more useful than the feature list because the entries differ in approach. A command line sign-in tool written in JavaScript on Nodejs targets the same single-platform workflow without a UI. A Python tool covers class sign-in, health check-ins, multiple users, multiple tasks and an API, which is the batch orientation this project does not have. A TypeScript tool that pairs with a QQ bot moves the trigger out of the phone and into a messaging integration. Another TypeScript entry does automatic sign-in for dreaming of completing online courses. A Python entry adds gesture, QR code, location and photo sign-in, and an Android-focused Java entry covers automatic sign-in on mobile. The last two lines are the interesting ones for anyone choosing: one is an Electron desktop client with a GUI and a sign-in queue, and one is a Python tool covering ordinary, photo, location, gesture and check-in code modes. The real difference between them is not the list of check-in types, since several cover the same ones, but whether the sign-in is triggered by a person or by a schedule, and whether there is a queue and a multi-user model.

Editorial conclusion

Adopt chaoxing-sign-app if you need a cross-platform client for the Chaoxing learning platform and you are prepared to deal with a reverse-engineered API that can break when the platform changes. Skip it if you need automatic sign-in, because that is still an unfinished item on the project list, and skip it if you cannot accept the reverse engineering involved. Before you rely on it, read the project declaration, which states that the developers have not authorised commercial or profit-making use of it, and check that your platform's own rules permit third-party clients.

Frequently asked questions

Official sources

1. eric-gitta-moore/chaoxing-sign-app on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases