Cleanup: identify and fix users affected by the id_token email-claim regression
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- authentication, database
Hướng nghiên cứu
Start by reading the issue's described fallback in lib/omniauth/strategies/codebar.rb and the listed cleanup queries; run the scans only after codebar/auth#83 is deployed. Keep emails and auth IDs in private ops notes, reporting counts and member IDs in the issue. Done means affected records are safely merged or re-keyed, members 31450 and 31452 are gone, no matching garbage records remain, and a magic-link sign-in resolves to the correct member.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The fix in codebar/auth#87 (PR codebar/auth#83) makes every id_token carry the user-record email and name claims. After it merges and deploys, the data damage from the regression still needs cleanup.
While the regression was live (auth release v64, 2026-10-02 10:01-16:34 UTC), a magic-link sign-in produced an id_token without an email claim. The codebar OmniAuth strategy fell back to sub (email = payload['email'] || payload['sub'] in lib/omniauth/strategies/codebar.rb) and created a planner member whose email and name were the better-auth user id: an empty account with no subscriptions or roles. Two such members are known: 31450 and 31452. Their users were dropped into the new-member flow as if they had never signed up. The rollback (v65) restored correct behaviour immediately: member 17284 has confirmed that sign-in works normally again. The window is therefore closed at 2026-10-02 16:34 UTC, and what remains is data cleanup.
1. Identify any affected users
- Find planner members whose
emailis a better-auth user id: members created in the window whoseemailmatches a 32-character opaque id, or whoseemailequals an auth user id directly. - Cross-check
auth_servicerows with providercodebarcreated in the window: a row whoseuidhas that same 32-character shape points at a garbage member. detect_duplicate_membersdoes not find these: the garbage member's email and name share nothing with the real member. Use the queries above, not the duplicate detector.- Keep the resulting user list out of this issue (emails and ids go in the private ops notes); report only counts and member ids here. Expected result: exactly 31450 and 31452 — earlier dump scans found no members of this shape before v64. The scan's real job is to confirm that and to catch anything the users created while stuck in the new-member flow.
2. Fix the identified users
For each affected user:
- If a real member exists (the usual case): merge anything the garbage member picked up (the user may have completed the new-member flow) into the real member, then delete the garbage member and its
auth_servicerow. 17284 is confirmed already: their real member is intact and in use, so only the garbage member (31452) goes. - If no real member exists (a genuinely new user who signed up during the window): re-key the member to the user's real email and name instead of deleting it.
- Confirm the user's next magic-link sign-in resolves to the same member. GitHub sign-ins already resolve via
github_idand are unaffected.
Verification before closing
- One magic-link sign-in resolves the real member on the fixed build (1.7.7 + explicit claims — different code path from the rollback that 17284 confirmed; member 17284 is the known case).
- No member has an email equal to a better-auth user id, and no
auth_servicerow has acodebaruid of that shape. - Members 31450 and 31452 are gone.
Timing: run this after codebar/auth#83 is deployed. Sign-ins after the fix can no longer create members of this shape.
- Ngôn ngữ chính
- Ruby
- Star
- 105
- Fork
- 206
- Merge trung bình
- 1 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 74
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của codebar/planner
-
DashboardQuery eager-loads workshop_host with :sponsors in one join (same host-loss trap as #2975)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của codebar/planner
Issue tương tự
-
Použiť Redis pre ActionCableĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
slovensko-digital/autogram-portal#392 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
voxpupuli/puppet-quadlets#122 · 5 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
TheOdinProject/curriculum#31452 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
revoir les metions de la DGEĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
betagouv/conseillers-entreprises#4720 ·
Maintainer thường phản hồi trong vòng 3 ngày