Username/password login page#1533
Conversation
| const addToast = useToast() | ||
| const { silo } = useSiloSelector() | ||
|
|
||
| const form = useForm({ defaultValues }) |
There was a problem hiding this comment.
It is rather pleasant to work with useForm directly like this. Something to think about. I wonder if our helpers like SideModalForm would be nicer to work with if we called useForm (or a wrapper hook that returns the same thing) outside them and passed the result in so the entire form instance was available to the calling code.
| </div> | ||
| <Logo className="absolute bottom-8 left-1/2 hidden -translate-x-1/2 sm-:block" /> | ||
| </main> | ||
| </> |
There was a problem hiding this comment.
nothing interesting here, just the extraction of the layout
| // if logged out, hit /login to trigger login redirect | ||
| if (result.statusCode === 401) { | ||
| // Exception: 401 on password login POST needs to be handled in-page | ||
| if (result.statusCode === 401 && method !== 'loginLocal') { |
There was a problem hiding this comment.
Without this change, we get a login redirect on bad login attempt, which is obviously not right. This method whitelist approach looks hacky, but it's exercised by the e2e test that looks for the error message on the login form. Will keep an eye on it, but I don't see a reason to get elaborate, for example by allowing the calling code to pass in a flag to exempt it from the login redirect. That would allow this function to not be aware of the method, but it would also require an annoying amount of plumbing through useApiMutation.
Closes #1457
The main thing of note here is that I'm only putting this page at
/login/:silo/localbecause that way, we know what silo you're trying to log into. This will work with the API as-is (with the trivial addition of telling it to serve the console bundle at that endpoint).The next step is to serve this page at
/loginand have it post to/v1/login. In that situation, the API gets to figure out what silo you want when it handles the POST. Console does not have to care about the silo, except for the fact that we want to display the silo name on the page. We could probably add the page at/loginwithout silo name already in this PR, and then once we have a way to get the silo name we can add it.