修改注册功能问题
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
# 2026-07-10 认证页表单校验和结构规范化计划
|
||||
|
||||
- 计划编号:PC-024
|
||||
- 开始时间:2026-07-10 14:56:08 +08:00
|
||||
- 页面范围:`login.html`、`register.html`、`forgot-password.html`
|
||||
- 接口范围:登录、短信登录、注册、找回密码提交前的本地校验与验证码取票据
|
||||
|
||||
## 结论
|
||||
|
||||
- 当前三页只有很弱的前端校验,主要是必填判断和找回密码两次密码一致校验,不算完整表单验证。
|
||||
- `<form>` 标签不是落后写法,它是提交类页面的语义结构;但把 `data-captcha-scene`、`data-success-url` 这类业务配置写在 HTML 上不够集中,后续维护容易散。
|
||||
|
||||
## 执行清单
|
||||
|
||||
1. [x] 写失败测试:认证页不能继续把业务配置写在表单 `data-*` 属性上。
|
||||
2. [x] 写失败测试:认证页 JS 要提供统一表单校验函数。
|
||||
3. [x] HTML 表单改为使用 `id` 作为挂载点。
|
||||
4. [x] `auth-pages.js` 增加统一表单配置和校验函数。
|
||||
5. [x] 保持三页提交前统一走 `CaptchaPages.ensureToken`,并继续使用 `payload.track` 换取票据。
|
||||
6. [x] 运行结构测试、业务测试、验证码测试、语法检查和空白检查。
|
||||
|
||||
## 验证记录
|
||||
|
||||
- 2026-07-10 14:56:08 +08:00:开始记录 PC-024,并补充结构和校验测试。
|
||||
- 2026-07-10 14:56:08 +08:00:`node tests\auth-page-structure.test.js` 与 `node tests\auth-pages.test.js` 已按预期失败,失败点为 HTML 未使用表单 `id`、JS 缺少 `sms-login` 场景配置和统一校验函数。
|
||||
- 2026-07-10 15:11:49 +08:00:修复后 `node tests\auth-page-structure.test.js`、`node tests\auth-pages.test.js`、`node tests\captcha-pages.test.js`、`node --check public\js\auth-pages.js`、`node --check public\js\captcha-pages.js` 均通过;`git diff --check` 无空白错误,仅有 LF/CRLF 换行提示。
|
||||
@@ -0,0 +1,20 @@
|
||||
# 2026-07-10 验证结果参数格式修正计划
|
||||
|
||||
- 计划编号:PC-021
|
||||
- 开始时间:2026-07-10 14:31:14 +08:00
|
||||
- 页面范围:`login.html`、`register.html`、`forgot-password.html`
|
||||
- 接口范围:`POST /captcha/verify`
|
||||
- 新契约:验证轨迹统一提交为 `payload.track`,不再提交旧的 `payload.data`。
|
||||
|
||||
## 执行清单
|
||||
|
||||
1. [x] 写失败测试:按后端最新示例断言 `payload.track`、`left`、`top` 和 `trackList`。
|
||||
2. [x] 修改 `captcha-pages.js`:把 TAC 轨迹转换成后端要求的 `payload.track`。
|
||||
3. [x] 更新追踪文档中旧的 `payload.data.trackList` 记录。
|
||||
4. [x] 运行焦点测试、语法检查和空白检查。
|
||||
|
||||
## 验证记录
|
||||
|
||||
- 2026-07-10 14:31:14 +08:00:开始按新请求体契约补失败测试。
|
||||
- 2026-07-10 14:31:14 +08:00:`node tests\captcha-pages.test.js` 已按预期失败,失败点为实际请求体仍提交 `payload.id` 和 `payload.data`。
|
||||
- 2026-07-10 14:34:28 +08:00:修复后 `node tests\captcha-pages.test.js`、`node tests\auth-page-structure.test.js`、`node tests\auth-pages.test.js`、`node --check public\js\captcha-pages.js` 均通过;`git diff --check` 无空白错误,仅有 LF/CRLF 换行提示。
|
||||
@@ -0,0 +1,26 @@
|
||||
# 2026-07-10 登录页样式与认证流程修正计划
|
||||
|
||||
- 计划编号:PC-022 / PC-023
|
||||
- 开始时间:2026-07-10 14:42:32 +08:00
|
||||
- 页面范围:`login.html`、`register.html`、`forgot-password.html`
|
||||
- 接口范围:登录、注册、忘记密码提交前的 `/captcha/verify` 取票据流程
|
||||
|
||||
## PC-022 登录页样式优化
|
||||
|
||||
1. [x] 优化 `public/css/login.css` 中登录方式切换区,让选中状态、文本居中和整体边框更自然。
|
||||
2. [x] 增加登录按钮与底部链接之间的间距。
|
||||
3. [x] 保持样式在 CSS 文件内,不用 JS 注入样式。
|
||||
|
||||
## PC-023 注册跳转与验证码流程复核
|
||||
|
||||
1. [x] 写失败测试:注册完成后必须跳转 `login.html`。
|
||||
2. [x] 写结构测试:三张认证页都必须声明验证码场景并携带 `validToken`。
|
||||
3. [x] 修改 `register.html` 的成功跳转。
|
||||
4. [x] 复核公共 `CaptchaPages` 仍统一按 `payload.track` 换取 `validToken`。
|
||||
5. [x] 运行相关测试、语法检查和空白检查。
|
||||
|
||||
## 验证记录
|
||||
|
||||
- 2026-07-10 14:42:32 +08:00:开始记录 PC-022 / PC-023,先补认证页结构测试。
|
||||
- 2026-07-10 14:42:32 +08:00:`node tests\auth-page-structure.test.js` 已按预期失败,失败点为 `register.html` 仍跳转 `create-genealogy.html`。
|
||||
- 2026-07-10 14:50:23 +08:00:修复后 `node tests\auth-page-structure.test.js`、`node tests\auth-pages.test.js`、`node tests\captcha-pages.test.js`、`node --check public\js\auth-pages.js`、`node --check public\js\captcha-pages.js` 均通过;`git diff --check` 无空白错误,仅有 LF/CRLF 换行提示。
|
||||
@@ -0,0 +1,128 @@
|
||||
# Registration Token State Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Ensure registration never creates or retains a browser authentication token, while password and SMS login continue to persist theirs.
|
||||
|
||||
**Architecture:** `utils/ApiClient.js` remains the single owner of browser token persistence. The `register()` method will leave its request and response contract unchanged, then clear the configured storage key after a successful response. `tests/api-client.test.js` will exercise the behavior through the public client methods and an in-memory storage adapter.
|
||||
|
||||
**Tech Stack:** Browser JavaScript (UMD), Node.js `assert` tests, Axios request adapter.
|
||||
|
||||
## Global Constraints
|
||||
|
||||
- Only `login()` and `loginBySms()` may persist a response token under the configured token key.
|
||||
- Successful `register()` clears the configured token key even when its response contains `token`, `accessToken`, or `tokenValue`.
|
||||
- Failed registration leaves existing token storage unchanged.
|
||||
- Registration page behavior remains a redirect to `login.html`.
|
||||
- Do not refactor unrelated request, storage, page, or authentication behavior.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Enforce registration token state in the API client
|
||||
|
||||
**Files:**
|
||||
- Modify: `tests/api-client.test.js:83-111`
|
||||
- Modify: `utils/ApiClient.js:176-182`
|
||||
|
||||
**Interfaces:**
|
||||
- Consumes: `client.register(body)` and `client.loginBySms(body)` from `GenealogyApi.createClient()`.
|
||||
- Produces: `client.register(body)` returns the API response while removing the configured token key after a successful request.
|
||||
|
||||
- [ ] **Step 1: Write the failing regression test**
|
||||
|
||||
Insert the following immediately after the existing `client.loginBySms(...)` assertions and before `client.sendSmsCode(...)` in `tests/api-client.test.js`:
|
||||
|
||||
```js
|
||||
assert.strictEqual(store.values['token-key'], 'server-token');
|
||||
|
||||
store.setItem('token-key', 'existing-token');
|
||||
const registerResponse = await client.register({
|
||||
phone: '13900000000',
|
||||
password: 'register-md5',
|
||||
nickName: 'new-user',
|
||||
validToken: 'register-ticket'
|
||||
});
|
||||
assert.deepStrictEqual(registerResponse, {
|
||||
token: 'server-token',
|
||||
url: '/genealogy/pc/auth/register'
|
||||
});
|
||||
assert.strictEqual(calls[8].url, '/genealogy/pc/auth/register');
|
||||
assert.strictEqual(calls[8].headers.Authorization, undefined);
|
||||
assert.strictEqual(calls[8].data.grantType, 'password');
|
||||
assert.strictEqual(calls[8].data.registerSource, 'PC');
|
||||
assert.strictEqual(store.getItem('token-key'), null);
|
||||
|
||||
const failedRegisterStore = createStore({
|
||||
'token-key': 'existing-token'
|
||||
});
|
||||
const failedRegisterClient = GenealogyApi.createClient({
|
||||
baseUrl: 'https://test-genealogy-api.ddxcjp.cn',
|
||||
clientId: 'client-x',
|
||||
tenantId: 'tenant-x',
|
||||
tokenKey: 'token-key',
|
||||
tokenStore: failedRegisterStore,
|
||||
axiosInstance: {
|
||||
request: async () => {
|
||||
throw new Error('register failed');
|
||||
}
|
||||
}
|
||||
});
|
||||
await assert.rejects(
|
||||
failedRegisterClient.register({
|
||||
phone: '13900000001',
|
||||
password: 'register-md5',
|
||||
nickName: 'failed-user',
|
||||
validToken: 'register-ticket'
|
||||
}),
|
||||
/register failed/
|
||||
);
|
||||
assert.strictEqual(failedRegisterStore.getItem('token-key'), 'existing-token');
|
||||
```
|
||||
|
||||
Move the existing `client.sendSmsCode(...)` assertions from index `8` to index `9`, then change the final call-count assertion from `9` to `10`.
|
||||
|
||||
- [ ] **Step 2: Run the regression test and confirm the current failure**
|
||||
|
||||
Run: `node tests/api-client.test.js`
|
||||
|
||||
Expected: failure at `assert.strictEqual(store.getItem('token-key'), null)` because the current `register()` implementation writes `server-token` to `token-key`. The failed-registration assertion will already pass, documenting that the token must change only after a successful response.
|
||||
|
||||
- [ ] **Step 3: Implement the minimal token-state change**
|
||||
|
||||
In `utils/ApiClient.js`, replace the body of `register()` with:
|
||||
|
||||
```js
|
||||
async function register(body) {
|
||||
var data = await request('POST', '/genealogy/pc/auth/register', {
|
||||
auth: false,
|
||||
body: Object.assign({ grantType: 'password', registerSource: 'PC' }, withTenant(body))
|
||||
});
|
||||
clearToken();
|
||||
return data;
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 4: Run the focused test and confirm it passes**
|
||||
|
||||
Run: `node tests/api-client.test.js`
|
||||
|
||||
Expected: `api-client tests passed`.
|
||||
|
||||
- [ ] **Step 5: Run the complete Node test suite**
|
||||
|
||||
Run: `Get-ChildItem -Path tests -Filter *.test.js | ForEach-Object { node $_.FullName }`
|
||||
|
||||
Expected: every test script prints its success message and PowerShell exits with code `0`.
|
||||
|
||||
- [ ] **Step 6: Check the final diff and commit the implementation**
|
||||
|
||||
Run: `git diff --check`
|
||||
|
||||
Expected: exit code `0` with no whitespace errors.
|
||||
|
||||
Then commit only the implementation files:
|
||||
|
||||
```powershell
|
||||
git add -- utils/ApiClient.js tests/api-client.test.js
|
||||
git commit -m "fix: clear token after registration"
|
||||
```
|
||||
Reference in New Issue
Block a user