rain/jiapu
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

修改功，现在补齐页面

Browse Source
This commit is contained in:
rain
2026-07-11 21:36:03 +08:00
parent db397a7917
commit a6038be376
143 changed files with 7218 additions and 11912 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/superpowers/specs/2026-07-10-registration-token-state-design.md
-29
View File
@@ -1,29 +0,0 @@
# Registration Token State Design
## Status
Pending written-spec review.
## Goal
Registration creates an account but never creates or retains a browser login state. Only a successful password login or SMS login may persist an authentication token.
## Contract Owner
`utils/ApiClient.js` owns browser token persistence. Pages invoke API methods and redirect according to their existing form configuration; they do not read, write, or clear the token directly.
## Required Behavior
1. `login()` and `loginBySms()` persist the token returned by their successful responses under `genealogy_auth_token`.
2. `register()` posts the existing registration request unchanged and returns its response unchanged.
3. After a successful `register()` response, `register()` clears `genealogy_auth_token`. This applies even when the response includes `token`, `accessToken`, or `tokenValue`.
4. If `register()` fails, token storage is not changed.
5. `register.html` continues redirecting to `login.html` after `register()` resolves.
## Scope
This change does not add a profile-page login guard, 401 redirect handling, or logout UI. Those are separate authentication-lifecycle steps that must consume the same `ApiClient` token contract.
## Verification
The API-client tests must prove that successful registration removes a previously stored token and does not store a token returned by registration. They must also retain coverage showing password and SMS login still store their returned tokens.
docs/superpowers/specs/2026-07-11-auth-to-profile-flow-design.md
-47
View File
@@ -1,47 +0,0 @@
# Auth To Profile Flow Design
## Status
Approved for implementation.
## Goal
Complete the PC journey from registration through login and personal-profile retrieval, with one token owner, deterministic redirects, and a single recorded API base address.
## Endpoint Configuration
`config.js` is the sole runtime owner of the API base address. Both development and production currently use `http://182.61.18.23:8080`. `tests/config.test.js` must assert that value. The PC integration tracker must record the change on 2026-07-11 and label prior test-domain references as historical rather than current configuration.
## Token Contract
`utils/ApiClient.js` owns token persistence under `genealogy_auth_token`.
1. Successful password login and SMS login must receive a nonempty response token, persist it, and then allow navigation to `profile.html`. The current backend response uses `data.access_token`; the client also accepts `token`, `accessToken`, and `tokenValue` for declared compatibility.
2. A login response without a token is an authentication failure. The login page remains in place and no profile navigation occurs.
3. Successful registration removes any existing token and navigates to `login.html`. Registration never persists a response token.
4. A failed registration leaves existing token storage unchanged.
5. `logout()` clears token storage in a `finally` path, so a failed or expired logout request cannot leave a local session behind.
## Page Flow
1. Registration validates fields, obtains `WEB_H5_REGISTER` captcha proof, posts `/genealogy/pc/auth/register`, clears token through `ApiClient.register()`, and redirects to `login.html`.
2. Password and SMS login validate fields, obtain `WEB_H5_LOGIN` captcha proof, post their respective login endpoint, persist the returned token through `ApiClient`, and redirect to `profile.html`.
3. `profile.html` and `profile-data.html` check for a token before requesting `/genealogy/pc/auth/profile`. Without one, they redirect to `index.html` without making the profile request.
4. A profile-read or profile-update error with HTTP status `401` or business code `401` clears token storage and redirects to `index.html`. Other errors remain on the current page and show the existing error message.
5. Confirmed logout calls `/genealogy/pc/auth/logout`, clears token regardless of the request outcome, and redirects to `index.html`.
## Ownership
- `config.js`: API base address.
- `utils/ApiClient.js`: login-token validation, persistence, clearing, and logout cleanup.
- `public/js/profile-pages.js`: profile-page token guard and unauthorized redirect.
- `public/js/profile-common.js`: confirmed logout action and redirect.
- `docs/pc-api-page-integration-tracker-2026-07-09.md`: current address record and end-to-end authentication status.
## Verification
Tests must prove the configured address, registration state, both login token paths, missing-token login rejection, logout cleanup after both success and failure, and profile unauthorized classification. Focused configuration, API-client, profile-page, and authentication tests must pass before the full Node test suite is run.
## Scope
This flow covers registration, password login, SMS login, profile retrieval and update on the two pages that load `/genealogy/pc/auth/profile`, and the existing profile logout action. Password reset, phone change, account deactivation, and profile pages without profile API loading remain outside this change.