-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(login) ensure a password is set, when using password login … #392
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #392 +/- ##
=======================================
Coverage 70.77% 70.77%
=======================================
Files 15 15
Lines 1728 1728
=======================================
Hits 1223 1223
Misses 442 442
Partials 63 63 ☔ View full report in Codecov by Sentry. |
e5040c4
to
690f1f5
Compare
…rove error message. fixes canonical#382 Signed-off-by: David Edler <[email protected]>
690f1f5
to
6359a7a
Compare
rebased on main and resolved conflicts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I tried it and it looks fine. Only question I have is wouldn't it be better to validate the fields before making the request? Not much of a difference tbh.
I think it is obvious that an empty password will not be a valid input that can be submitted. So an error shouldn't be a surprise or cause of frustration as it is expected not to work without a password. |
That's not what I meant. In this PR we check if the password is unset and if it is unset we set it to |
I understand your concern was about a possible optimization to avoid sending the request for validation. It is pretty hard to do the validation client side. This is due to the architecture with kratos sending flows of objects. On submit, we can't easily set an error on the password input field, because that is in a different component. We could do it via DOM manipulation. Actually, we do that for in other cases to ease the UX. I am not sure adding this complexity is worth the hassle. Especially as the extra request for validation here should be tiny and quick. I assume in the UX it doesn't make a big difference given a reasonably stable and fast connection. |
Understood, thanks |
to improve error message.
fixes #382