Email `code` strategy needs more explanation in the docs
Closed this issue · 2 comments
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.
- This issue affects my Ory Network project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe your problem
The docs do not explain why the verification code flow gives both the .VerificationCode and .VerificationURL, but the .RecoveryCode and RecoveryURL only gives access to the code and not a URL like with verification.
The reason for recovery not getting the URL as well is due to the URL being shared / intercepted and the session being hijacked (?) /cc @jonas-jonas
Since the Recovery flow is a more high-risk operation giving access to a session, the code needs to be entered manually by the user. The Verification flow does not give access to a session so is low-risk.
http://localhost:3000/docs/kratos/emails-sms/custom-email-templates
Describe your ideal solution
A document describing in detail why the recovery code method only gives a code and not a URL with the code.
Workarounds or alternatives
None
Version
latest
Additional Context
No response
The reason for recovery not getting the URL as well is due to the URL being shared / intercepted and the session being hijacked (?) /cc @jonas-jonas
It's because the flow is protected against CSRF attacks. If we include a link, we can no longer do that. User's would have to open the link in the same browser and immediately after initiating recovery, without doing/visiting other flow pages.
A document describing in detail why the recovery code method only gives a code and not a URL with the code.
A whole document is a bit overkill. But I guess a section in https://www.ory.sh/docs/kratos/self-service/flows/account-recovery-password-reset and on the email templates page would help. Agreed.
Hello contributors!
I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue
- open a PR referencing and resolving the issue;
- leave a comment on it and discuss ideas on how you could contribute towards resolving it;
- leave a comment and describe in detail why this issue is critical for your use case;
- open a new issue with updated details and a plan for resolving the issue.
Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.
Unfortunately, burnout has become a topic of concern amongst open-source projects.
It can lead to severe personal and health issues as well as opening catastrophic attack vectors.
The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.
If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.
Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!
Thank you 🙏✌️