36 lines
2.8 KiB
Markdown
36 lines
2.8 KiB
Markdown
## Context
|
|
|
|
Server deletion currently reuses the archive path and already restricts the action to the instance owner or a platform administrator. What it does not do is re-check the caller's password before removing the server from active use, which leaves a destructive action one click away once a session is active.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
- Require a password confirmation before server deletion is accepted.
|
|
- Preserve the existing owner/platform-admin authorization rule.
|
|
- Keep the current soft-delete behavior that marks the server instance deleted and preserves history.
|
|
|
|
**Non-Goals:**
|
|
- Implementing hard delete or permanent record erasure.
|
|
- Changing unrelated server lifecycle permissions.
|
|
- Adding a new authentication system or password reset flow.
|
|
|
|
## Decisions
|
|
|
|
- Keep the existing `DELETE /api/v1/server-instances/{id}` route and extend it with a JSON body containing the current password. This avoids inventing a parallel delete endpoint and keeps the UI and API aligned.
|
|
- Verify deletion authorization in the service layer, not only in the frontend. The request must still be rejected even if the browser skips the confirmation UI.
|
|
- Reuse the current session user's stored password hash and existing `verifyPassword` helper. No new credential store or token exchange is needed.
|
|
- Return a generic forbidden response when the password confirmation fails. The UI can present that as a password-confirmation failure without exposing hash or account details.
|
|
- Surface deletion from the server list card's "运行操作" popover in a "危险操作" group instead of placing it inside the detail metadata panel. Runtime actions remain permission-gated, while eligible creators/owners and platform admins can still reach the delete confirmation.
|
|
- Update the user-facing copy from "归档" to "删除" so the destructive intent is clear wherever the action is exposed.
|
|
|
|
Alternatives considered:
|
|
- Separate confirm endpoint: rejected because it adds another round trip without changing the security model.
|
|
- Query-string password: rejected because sensitive data should not live in the URL.
|
|
- Hard delete: rejected because the platform already models server removal as a deleted state with retained history.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [Risk] Sending a password in the request body increases sensitivity of the delete call. → The request already runs over authenticated HTTPS; the frontend must avoid persisting the value beyond the dialog.
|
|
- [Risk] The UI and API could drift if one side keeps "archive" wording or if the delete entry reappears in details. → Keep the confirmation dialog and API call site in the list runtime action flow together.
|
|
- [Risk] Password confirmation may feel redundant to power users. → Keep the rule limited to destructive deletion only, not to normal lifecycle operations.
|