jwag956
commented
8 months ago Definitely a bug - and in fact there are a few of these in various templates. I'm embarrassed that unit tests didn't pick this up. Let me look at how best to fix this - in keeping with the change - just referencing current_app.config[xxx] might be best and most consistent.
Flask injects 'config' so I think the answer is: {% if config["SECURITY_USERNAME_ENABLE"] %}
I am working on that (there are a few others) as well as unit tests. Hope to get a PR later today.
I recently migrated to version 5.4.2 from version 5.1.1 and ran into an issue where my registration page no longer showed the username entry. I did some further digging and noticed that the username entry will only appear if SECURITY_USERNAME_ENABLE is set to true. This was being indeed set in my app and rolling back to the previous version worked. I did some more digging and noticed that the Security class no longer had the username_enable attribute defined that was being handled by the template (see below).
from flask_security\templates\register_user.html:
{% if security.username_enable %}{{ render_field_with_errors(register_user_form.username) }}{% endif %}I did some more digging and found that in the change linked below, a change was made to stop dynamically creating attributes for all of the SECURITY config variables.
https://github.com/Flask-Middleware/flask-security/commit/96d9489e63e6382fae0d76c12d85acc6800a1dad
Was the removal of this attribute an oversight? Was the default template supposed to be updated? If it was just an oversight, it appears adding "username_enable" to the attr_names list would take care of the issue. Please let me know if you would like me to create a PR with this change. Thanks in advance!