# Connect pages, identity, and backend data in a mini program

Canonical page: https://yishto.com/en/learn/application-platforms/wechat-learning-miniapp/

Author: [Yishto](https://yishto.com/en/about/)

Design a learning-progress mini program with page boundaries, server-side login exchange, record authorization, network-response handling, and device domain validation.

Published: 2026-11-10
Updated: 2026-11-10

A learning-progress mini program shows courses, lessons, and completion counts. The page submits intent; the server establishes identity and authorizes records. A client-supplied user ID cannot determine access, because a modified request could target someone else's progress.

Use synthetic course and account identifiers. Begin with lists, sessions, and progress endpoints without collecting phone numbers or adding payments. Self-managed servers and cloud functions need the same authorization boundaries.

## Separate page state and stored records

A course has ID, title, and lesson count. Progress has user ID, course ID, completion representation, and version. Load bounded summaries and bodies instead of putting the entire catalogue in page data. Distinguish loading, empty, failed, and successful states.

WXML describes the page, WXSS styles it, and the logic layer handles events through platform APIs. This is not an unrestricted browser or Node environment. Check dependencies against the selected base library. Validate request and course identity before applying responses arriving after navigation.

A maximum lesson number implies all previous lessons are complete. Supporting out-of-order learning requires a set or equivalent records. The example uses a count for simplicity; choose the real representation from product rules.

## Exchange temporary login codes on the server

`wx.login()` returns a temporary code that is sent to the developer server. The server calls official `auth.code2Session`, maps identity, and establishes its own application session. A code is single-use and is not a long-lived access token for progress requests.

Keep AppSecret on the server and never expose `session_key` to the mini program. Map OpenID to an application account. UnionID availability has documented conditions and cannot be assumed. Verify an application session to derive the user for business requests.

Logging in and obtaining profile data are different actions. Recording progress does not require collecting every personal detail. Expired sessions trigger a new code exchange. Handle reused or invalid codes without logging secrets or complete credentials.

## Build the client and backend

Create a native project in WeChat Developer Tools and record base-library and project settings. Declare course and reader page paths. Start with synthetic local JSON to verify navigation, bounded data, and returning from detail.

Create login-exchange and progress endpoints. The login endpoint accepts a code, uses server-held platform credentials, and returns an application session. Progress endpoints verify session, course existence, value bounds, and ownership. Define database uniqueness for the user-course pair to avoid duplicate records.

Centralize client requests in a service module handling timeout, HTTP status, and business errors. Confirm saves only after acknowledgement, retaining retry information on failure. Cloud functions also need invocation-context checks and data rules; cloud development does not automatically authorize every record.

## Check ownership with an offline contract

The Python model checks ownership for an already-established user. `U-2` cannot read `U-1`'s progress. It runs no login exchange, session verification, WeChat API, or database.

```python
records = {"P-1": {"owner": "U-1", "progress": 3}}
def progress(user, record_id):
    record = records.get(record_id)
    if record is None or record["owner"] != user:
        return None
    return record["progress"]
assert progress("U-1", "P-1") == 3
assert progress("U-2", "P-1") is None
print(progress("U-1", "P-1"))
```

The output is `3`. Unauthorized access returns `None`. A real endpoint derives the user from its verified session, never arbitrary request data. Decide whether missing and forbidden records share a response based on information-disclosure policy.

Writes also enforce ownership and bounds. Completion counts cannot be negative or exceed the course range. Define migration when lesson versions change. Validation and identity checks are separate requirements and both must pass.

## Interpret callbacks and domain conditions

The official networking guide explains that receiving a response can invoke `success` even when its HTTP status indicates an error. Check status codes and business results before confirming a save. Authentication, validation, and service failures need different recovery.

Configure ordinary request domains according to current rules, using HTTPS and valid certificate, protocol, and port settings. Sensitive platform exchanges stay on the server. Documented cloud-hosting call exceptions do not apply to every network request.

Development tools can temporarily bypass domain and certificate checks. Final verification disables those options and tests devices outside debug mode. Debug-only success still requires configuration investigation. Check current limits and base-library conditions rather than hardcoding enduring numbers into the lesson.

## Recover retries and navigation

Timeout does not prove the write failed. Use stable operation identity or an explicit idempotency contract. Update confirmed versions and reject obsolete responses. UI button disabling helps interaction but does not replace server duplicate handling.

Backgrounding can interrupt requests. Reopening reloads confirmed progress and handles unacknowledged operations. If offline changes are allowed, persist pending work and its baseline and show waiting-for-sync status instead of presenting an increased count as saved.

On account changes, clear the previous user's page cache and local record associations before loading the current account. Define storage scope so another person using the device does not see earlier progress.


Return the accepted completion range and confirmed version, displaying only what the server acknowledged. Pagination retains query and cursor identity and avoids duplicate rows on retry. Keep interface changes compatible or state an upgrade requirement because older mini-program packages may remain in use.

## Exercise: test identity and failure

Use two teaching accounts against one record; the second must neither read nor modify it. Test invalid codes, expired sessions, HTTP errors, duplicates, and responses arriving after navigation. Data and status must agree.

Verify both tools and devices, finally disabling debug and validation bypasses. Check client packages and logs for absent AppSecret, session_key, and service secrets. Only the ownership model runs here; exchange, networking, and persistence need actual project testing before adding course search.

## Sources & further reading

- [Mini program framework documentation](https://developers.weixin.qq.com/miniprogram/dev/framework/)
- [Mini program login flow](https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html)
- [Mini program network requests](https://developers.weixin.qq.com/miniprogram/dev/framework/ability/network.html)

Sources checked on 2026-11-10. Examples are teaching data, not production measurements.

## Related guides

- [API contracts: parameters, identity, access, and errors](https://yishto.com/en/learn/service-data/http-api-contracts-and-access/)
- [Project: a training exercise and answer-record system](https://yishto.com/en/learn/project-labs/lab-training-assessments/)