feat: fields should automatically trim whitespaces around values (e.g. OTP)
jonasbadstuebner opened this issue · 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 Cloud project.
- I have joined the Ory Community Slack.
- I am signed up to the Ory Security Patch Newsletter.
Describe your problem
When I double clicked and CTRL+C-ed the OTP from my mail, it copied a whitespace in front of it and I didn't notice, only after the form told me, the OTP was wrong.
Describe your ideal solution
Maybe there is an easy way to trim the value of some fields, where it makes sense. This is minor priority, but very convenient. :)
Workarounds or alternatives
Don't know if there are any workarounds right now - probably only implementing this whole library on your own?
Version
v0.0.1-alpha.27
Additional Context
No response
Oh, great idea! We could actually do this in Kratos itself, so that this would apply to other implementations as well. @aeneasr WDYT?
I don't think the whitespaces are coming from Kratos, so fixing this in Ory Elements is a good idea :)
They are not coming from kratos, but if kratos would ignore/trim them, the frontend/selfservice would not have to handle that.
Still I think it would be best to implement it in ory elements. :)
Fixing this issue in Ory Elements would require JS to trim the data, so not that good.
I think that the best would be for Kratos self-service to return an input field that contains InputAttribute.Pattern with valid characters that I think in this case would be [a-zA-Z0-9]+.
A change to CSS would be a good to show error border when pattern does not match. Currently that is shown only when there is no focus to the field.
This would be nice also in other places for example recovery code input.
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 🙏✌️