Emails freed up by an admin email change can be reassigned to a new user (no history tracking)
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- typescript
調査の方向性
Start by reading UsersController.createUser around lines 187–197, then compare the email-change paths in UsersController.updateUser and ProfilesController.updateProfileById. This issue asks the team to decide whether email history should prevent reuse outright, enforce a cooldown, or remain a known trade-off; implementation and a definition of done depend on that decision.
索引モデルが issue の本文から書いたものです。
説明
UsersController.createUser checks for duplicate emails against current and soft-deleted users:
count({ where: { email, deleted: true } })triggers "This email belongs to a deleted user, you must restore the user instead of creating a new one"count({ where: { email } })triggers "Email already exists"
There's no history table or history check. If an admin changes User A's email from [email protected] to [email protected] via UsersController.updateUser or ProfilesController.updateProfileById, [email protected] becomes fully free to reassign to a new User B via create-user or invite. Delete already handles this correctly via soft-delete, but change does not — deleted users keep their emailHash reserved, changed users release it.
Consequence: if User A still has access to that mailbox they'll receive emails intended for the new User B (registration link, reset link, notifications). Password-reset links for the old address become invalid, but any pending or previously-received emails are still readable. Social engineering and info-leak vector.
Auth0 and similar providers keep an email-history table specifically to prevent this. Modern guidance is split on whether to block reuse outright or allow it after a cooldown (e.g. 90 days), so filing as a question — worth a team decision on whether we want history enforcement in the health context, or whether accepting the current behaviour as a known trade-off is fine.
Related to #929 which is about notification on email change, and #928 on reset completion.
Related files: UsersController.createUser (lines ~187-197), UsersController.updateUser, ProfilesController.updateProfileById.
- 主要言語
- TypeScript
- スター
- 4
- フォーク
- 0
- 平均マージ
- 14時間 50分
- マージ済み PR（30日）
- 5
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
Garvan-Data-Science-Platform/ctrl のほかの issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 82/100
-
admin-client backend bug
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
-
backend bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Garvan-Data-Science-Platform/ctrl#970 · コメント 1 件 ·
-
backend bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
backend bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Garvan-Data-Science-Platform/ctrl の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 83/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ranxianglei/billion-context#3583 ·
メンテナーはふだん 1 日以内に返信
-
bug:new
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
callstackincubator/simlock#673 ·
メンテナーはふだん 1 日以内に返信
-
documentation v3
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 73/100
anomalyco/opencode#56380 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信