Field Error in Reauthentication Form

[Daksh2000]

Fixes: #16460

For proper error in password field while reauthenticating, I made some changes in reauthenticate function, adding a renderer
and returning HTTP status code 303 only in case if all form fields validation are successful , otherwise re render the form with appropriate error.

[Daksh2000]

Issue: #16460 (comment)

For proper error in password field while reauthenticating, I made some changes in reauthenticate function, adding a renderer and returning HTTP status code 303 only in case if all form fields validation are successful , otherwise re render the form with appropriate error.

Hi @di , Please share your views.

[Daksh2000]

Issue: #16460 (comment)
For proper error in password field while reauthenticating, I made some changes in reauthenticate function, adding a renderer and returning HTTP status code 303 only in case if all form fields validation are successful , otherwise re render the form with appropriate error.

Hi @di , Please share your views.

Hi Team, could someone review this change

[Daksh2000]

Issue: #16460 (comment)
For proper error in password field while reauthenticating, I made some changes in reauthenticate function, adding a renderer and returning HTTP status code 303 only in case if all form fields validation are successful , otherwise re render the form with appropriate error.

Hi @di , Please share your views.

Hi Team, could someone review this change

Hi @di , looking forward for updates on this PR

[di]

This mostly works but has the effect of changing the URL to /account/reauthenticate/ if the password is wrong, since in that case it renders the current view rather than redirecting.

As a result, visiting /account/reauthenticate/ directly always asks the user to re-authenticate (since the request is not a GET) and it never redirects elsewhere, even if the password is correct (because next_route is the same as the reauthentication route).

I think we might need to find another way to do this that doesn't require the view to render the page. Some options:

• We could flash any errors instead: this wouldn't be great because we don't do this elsewhere
• We could store any errors on the redirect_to route to make them accessible to the rendering page (like we do with next_route_matchdict and next_route_query)