Passing login/register field errors without Flask-WTF

[magma764]

I've created new custom templates for login/registration as per the documentation and they're mostly working as expected. I included blocks for Flask message flashing. For various reasons, I did not leverage Flask-WTF for form rendering and would prefer to keep it that way.

It seems a side effect of this choice is that the front end will not render messages like "email is already associated with an account" if a duplicate email is used for registration, which you would see on the default security /register view. It looks like they are passed by the render_template_with_errors macro which is defined in templates/security/_macros.html. Is this tied to using Flask-WTF? The page will flash correctly when an anonymous user tries to access a protected endpoint.

What do I need to do to pass all the messages?

[jwag956]

First - the way I think about flashing versus validation errors is that flashing is useful when the operation ends up redirecting the user to a different page/form - and the 'flash' gives information about why (e.g. successful login).
If there are errors that the user should fix - such as validation errors - those are better returned as part of the form so the user can fix and re-submit.

I am a bit confused - you say you added new templates - but sounds like you are still using the same default forms. All Flask-Security forms are based on Flask-WTF. You can override those forms - but then you are repeating a lot of work.

When you say 'did not leverage Flask-WTF for form rendering' I am not sure what you mean - the template rendering is done (by default) Flask's render_template() method. So you should be seeing all the errors in your response form (unless you did override the forms as well). Flashing is outside of any form and is implemented using Flask::flash and Flash::get_flashed_messages (which your templates can call)

If you really don't want to use Flask-WTF - then you have to define all your own forms including validation etc - and be sure to implement CSRF protection.

Now - possibly you are asking - can I flash all errors instead of returning some as validation errors on a specific field... Hmm - I think that could be done by implementing a context_processor and in that look for errors and turn them into flashes....

[magma764]

Let me clarify - I created new forms from scratch using plain HTML and Tailwind CSS, so none of the Flask-WTF field context was being forwarded. I did create a new context processor to include CSRF protection as per the documentation.

I found a middle ground by using a modified version of render_field_with_errors from _macros.html to pass the classes and attributes to render Tailwind correctly and still calling the default Security form elements into the templates. It looks something like {{ render_field_with_errors_cust(register_user_form.email, error_class="...", class_="...", placeholder="..") }}
Whereas previously I didn't call the Security context in the template at all.

Flask-WTF looks like a great tool and I'd be using it if I was the only person working on the project, however our front-end devs have a different approach and it would be a hassle to get them to define new forms in Python as opposed to using a template or page builder.

Your suggestion of creating a new context processor makes sense, but only if your template references the WTF form elements to begin with, and then you might as well just use render_field_with_errors or customise it - since I agree it makes more sense to show the error in a field context as opposed to a flashed message (which is typically at the top of the page or some arbitrary location)

Thank you for the detailed response.

[jwag956]

Got it - just another note - Flask-Security supports a JSON API and extensive support for SPA (e.g. Vue, React, Angular). So in my application for example - the UI defines its own forms (I am using Vue) and simply uses AJAX to talk to FlaskSecurity API endpoints. With that the UI is completely decoupled.