Signage Devices
API fact source: Django backend generated docs
In Chinese product terminology, "班牌" is called "Signage Devices" in the English documentation.
Why Devices Do Not Use User Login
signage owns device lifecycle, device authentication, display configuration, and device-side schedules. A signage device is a long-lived terminal mounted near a classroom, so it is not tied to a user session. Device endpoints use independent device tokens; admin endpoints use normal user authentication.
Code entry:
backend/apps/signage/models/backend/apps/signage/views/backend/apps/signage/serializers/backend/apps/signage/authentication.pybackend/apps/signage/tokens.py
Device Identity
SignageDevicebinds one-to-one withClassroom.- Activation codes and device tokens are stored only as hashes; plaintext values are returned only when issued.
- Device endpoints use only
Authorization: Bearer <device_token>. - Admin endpoints use normal user authentication, currently limited to
superadmin.
Schedule Source
Device schedules read only CourseOccurrence and do not merge manual reservations. This keeps the display close to the teaching timetable and avoids showing pending ad hoc reservations as class schedule. If reservations need to appear later, first define the Android data shape, cache behavior, and display priority.
Activation And Tokens
Activation codes are one-time credentials. Device tokens are long-lived credentials. Plaintext values are returned only at issuance time; the database stores hashes. Activation changes need to preserve one-time activation, device uniqueness, and token revocation.
Open Boundaries
- Signage can expose face registration/recognition-related requests, but the main check-in flow does not yet depend on it.
- Integrating face-service or check-in writes needs a separate design for device identity, student identity, replay protection, fallback behavior, and operation logs.
- APK updates, display configuration, and schedules are device operations, not part of the user permission model.