Should we allow creation of participants with uuids provided by the client?
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
Hướng nghiên cứu
Bắt đầu bằng việc đọc issue #128 và hành vi participant upsert hiện tại trong quá trình tạo ủy quyền và bỏ phiếu. Làm rõ liệu có nên chấp nhận các participant UUID do client cung cấp hay không, sau đó ghi lại các quyết định về bảo mật của mã định danh, các UUID chỉ-đọc và các mã định danh tạm thời.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
This has come up during investigation of #128, and needs further discussion:
One of the reasons we decided to use uuids as ids is to enable passing around of identifiers to/from clients and other services, and we're supporting for pre-existing resources in our system - votes, delegations and participants already persisted in the database.
Currently we support upserts of participants on delegation and voting creation based on emails provided by the client.
Another potential scenario is when the client already generates uuids for their participants (for which they're the source the truth), and submits that to us instead of an email. For instance, when creating a delegation, submitting delegator_id and delegate_id instead of a delegator_email and delegate_email. This could be a way to improve the privacy of the participant in our system. We'd only know their client-side id.
Questions raised so far:
- YAGNI?
- any security issues with passing around a direct db identifier like that?
- in some instances clients will create a view-only uuid, and sometimes that's ephemeral. How do we handle that?
- Ngôn ngữ chính
- Elixir
- Star
- 17
- Fork
- 3
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
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 liquidvotingio/api
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
liquidvotingio/api#252 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
liquidvotingio/api#250 ·
-
Proposal collection reference fieldCó thể làm lại được @oliverbarnes đã nhận 1980 ngày trước và không có pull request nào đang mở. Đang mở
liquidvotingio/api#245 · 3 bình luận · 1 người được giao ·
-
Make better use of Multi.runĐang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 48/100
liquidvotingio/api#237 ·
-
Make global delegations explicitĐang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
liquidvotingio/api#234 · 1 bình luận ·
Tất cả issue của liquidvotingio/api
Issue tương tự
-
CLI auth policy save crashes with NotFound when the AuthorizationSettings singleton is missingĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
carverauto/serviceradar#5009 ·
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 86/100
phoenixframework/phoenix_live_view#4456 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
L: docker L: elm L: github:actions L: helm L: ruby:bundler
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
dependabot/dependabot-core#16425 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
bug javascript
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/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 78/100
blockscout/blockscout#14878 ·
Maintainer thường phản hồi trong vòng 1 ngày