Ability to query for identity properties without admin rate throttling
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
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- api, authentication
Hướng nghiên cứu
Xem lại endpoint getIdentity đã được ghi lại và hướng dẫn về giới hạn tốc độ cho /sessions/whoami, sau đó so sánh mục đích sử dụng và các giới hạn của chúng. Hoàn thành nghĩa là đã quyết định thiết kế API cho việc truy xuất thuộc tính danh tính theo thời gian thực, bao gồm việc có hỗ trợ tra cứu danh tính theo lô hay không và giới hạn tốc độ của nó sẽ hoạt động như thế nào; issue không nêu tên tệp hoặc bài kiểm thử nào trong repository.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Preflight checklist
- I could not find a solution in the existing issues, docs, nor discussions.
- I agree to follow this project's Code of Conduct.
- I have read and am following this repository's Contribution Guidelines.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Ory Network Project
xenodochial-mestorf-alar1uohvl
Describe your problem
We've been using Ory as a single source of truth for user properties, avoiding replication within our application data so as not to increase our exposure to PII. The key properties in our application are user email address and 'display name', both of which are retained solely with Ory.
We have a need to surface this data to our front end, however, in various user listings pages (e.g. listing users who are a member of a team). To achieve this, we've been pulling these properties via our backend calling the https://www.ory.sh/docs/reference/api#tag/identity/operation/getIdentity endpoint
The issue we've encountered is that this solution does not scale, due to rate limiting on the Ory side. Indeed, it would seem this API is not expected to be used for the kind of realtime, user facing use flow we're currently employing it for.
We can address the problem by replicating these properties in our application, but at the cost of maintaining this PII ourselves.
As such, it would be desirable if Ory supported identity property retrieval via an API for such real time use cases such as the one I've described.
Describe your ideal solution
The existence of an API for retrieval of identity properties for any user with rate limiting aligned with the /sessions/whoami (etc) APIs (ref)
Bonus points if the API could accept a set of identities IDs to retrieve properties for
Workarounds or alternatives
Replicating the PII our side, avoiding the need to query Ory for such flows
Version
Ory Network (i.e. your managed, cloud solution)
Additional Context
No response
- Ngôn ngữ chính
- Shell
- Star
- 95
- Fork
- 7
- 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
- Không có Dockerfile hay tệp Docker Compose
- 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 ory/network
-
feat
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
-
Updating native registration flow with OIDC ID token for existing identity returns breaking responseĐang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
Ory Account Experience (hosted UI) registration trait setup via creation of registration flowĐang mởfeat
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
selfservice.flows.login.style reverts to identifier_first despite explicitly setting passwordĐang mởbug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
Issue tương tự
-
Agents panel: Codex token stats always empty because Codex now writes `*.jsonl.zst` sessionsĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 2 ngày
-
needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
mattpocock/skills#1307 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
status: ready
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
melodic-software/claude-code-plugins#8537 ·
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 84/100
vladmandic/sdnext#5161 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
severity: low
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 89/100
luainkernel/lunatik#1980 ·
Maintainer thường phản hồi trong vòng 1 ngày