kama-frontend-auth-lite

name

kama-frontend-auth-lite

description

Update a Kama Chat Vue frontend from the course SMS-auth flow to this repo's simplified backend contract: keep telephone+password login, simplify register to nickname+telephone+password, remove SMS login, and align routes/buttons/forms with `/login`, `/register`, and the disabled placeholder `/sendSmsCode` endpoint. Use this when editing Login/Register/SmsLogin pages, router guards, auth API wrappers, or navigation buttons.

Kama Frontend Auth Lite

Overview

Use this skill when the frontend still follows the course's 短信注册 / 短信登录 flow, but the backend has been simplified to:

• keep 手机号 + 密码登录
• keep 昵称 + 手机号 + 密码注册
• 不实现短信登录
• keep POST /sendSmsCode only as an optional 未启用占位接口

If the frontend repo structure differs from the course demo, first search for smsLogin, sendSmsCode, sms_code, handleSmsLogin, handleRegister, and router.beforeEach.

Backend Contract

Treat the current backend code as source of truth, even if older course docs still mention /user/sendSmsCode or /user/smsLogin.

Target this contract:

• POST /login
  • body: { telephone, password }
• POST /register
  • body: { nickname, telephone, password, sms_code? }
  • backend ignores sms_code
• POST /sendSmsCode
  • body: { telephone }
  • returns a business warning that SMS is not enabled
• there is no usable SMS login endpoint in the current backend

Load references/backend-auth-contract.md if you need the exact repo evidence before changing code.

Required Changes

1. Login page

• Keep the existing telephone + password form and POST /login call.
• Keep current success handling: toast, normalize avatar URL when needed, store userInfo, then route to the chat page.
• Remove or disable any 验证码登录 button and any navigation to /smsLogin.

2. Register page

Recommended minimal-cost change:

• Remove the 验证码输入框 and 发送验证码 button from the UI.
• Validation should only require nickname, telephone, and password.
• Keep nickname length validation and telephone format validation.
• Submit to POST /register.
• Request body may:
  • omit sms_code, or
  • keep sms_code: "" if removing the field would create larger refactors.
• Keep current success handling: toast, normalize avatar URL when needed, store userInfo, then route to the chat page.

Fallback if you must keep the component shape temporarily:

• Keep registerData.sms_code in local state, but make it optional.
• Do not block register on sms_code presence.
• Do not require a successful send-code request before allowing register.

3. SMS login flow

• Remove the /smsLogin route.
• Remove /smsLogin from router allowlists or unauthenticated-route checks.
• Remove buttons or links that navigate to the SMS login page.
• Remove SmsLogin.vue imports and page references if they become unused.
• Remove handleSmsLogin logic unless the product explicitly wants to keep a disabled placeholder page.

4. Send-SMS placeholder handling

Preferred:

• Remove all send-code UI from register/login, because SMS is not part of the current product capability.

Optional fallback:

• Keep a small button that calls POST /sendSmsCode only to show the backend warning.
• If you keep this button, the UI message should clearly say 短信服务未启用 rather than pretending the code was sent.

Implementation Workflow

1. Inspect router, auth pages, and shared API wrappers.
2. Replace any /user/sendSmsCode call with either:
   • no call at all, or
   • POST /sendSmsCode if a disabled placeholder is intentionally retained.
3. Remove any /user/smsLogin call; do not replace it with a fake login flow.
4. Simplify register form validation so it no longer depends on sms_code.
5. Remove SMS-login buttons, routes, and dead code.
6. Verify that login and register still store user info and navigate correctly.

Validation Checklist

After edits, verify:

• password login still works
• register works without SMS code
• no page still posts to /user/smsLogin
• no page still hard-requires sms_code
• no misleading success text says a code was sent when SMS is disabled
• router no longer exposes the SMS login page unless you intentionally kept a disabled placeholder

Output Expectations

When using this skill on a frontend repo, report back with:

• which auth pages/routes/buttons were changed
• whether sms_code was removed or kept as optional local state
• whether send-code UI was removed or downgraded to a disabled placeholder
• any remaining frontend file that still references SMS auth and should be cleaned later