WTForms 3 / deprecated SecureForm

[MM1nd]

WTForms 3 will remove deprecated Extensions, namely SecureForm. This has already been done here: https://github.com/wtforms/wtforms so I guess things are getting serious.

tl:dr; I did something about that.

For what it's worth, I made a fork that does the following:

• Do not longer inherit from SecureForm, but directly from Form
• Make use of WTForms class Meta to configure CSRF
• Remove functionality to generate/validate csrf tokens from both the form and the csrf module and let this be handled by the functionally equivalent SessionCSRF from WTForms to reduce redundancy. Also as to not have two subtly incompatible implementations in place.
• Make changes to CsrfProtect as to use SessionCSRF in place of the old implementation. Currently it works by creating a Dummy Form on generation and vaildation of csrf tokens. There ought to be a better solution but that will probably require even more changes to CsrfProtect or new code redundancy.

[As an aside: In principle there is an alternative to this approach which is to provide an implementation of WTForms CSRF base class, that uses flask-wtf's csrf implementation. But since the implementations were functionally equivalent I saw no use in that. If you absolutely must keep the current CsrfProtect implementation unchanged, however, that's the way to go. Then again, my changes should make it easier to plug other implementations of WTForms CSRF into CsrfProtect, which in and of itself is a plus.]

(Maybe unfortunately) I also made some flavour changes:

• Removed hidden_tag() which I personally found to be counter intuitive. IMO this should be solved on field level.
• Included widget for HiddenInputs that retains most of hidden_tag's old functionality in the place where it belongs IMO.
• Modified tests as to work without hidden_tag()
• Modified tests as to work out of Visual Studio (yeah, sorry about that one)

I know the latter list will be controversial and contains breaking changes therefore I will make no pull request. However, feel free to head over to https://github.com/MM1nd/flask-wtf and use whatever you like.

Alex

[crast]

WTForms 2 has been out in the wild for about two years, there's very little chance there are people out there using WTForms 1 (as the compatibility was pretty solid) and most likely they won't have a huge issue upgrading to WTForms 2 (or even 3).

Also see this comment from back when wtforms 2 was a thing for reference #94 (comment)

@lepture @MM1nd WTForms 3 will not be released before March, and it is a priority to not break any companion libraries (or provide solid upgrade paths) - so I am open to any opinions or anything I can do to ease the transition. There is still room for API additions or backwards-incompatible changes; so if there's something that's a headache about WTForms integration support - send a ticket/PR over our way

But I do recommend you do this right away:

1. Perhaps release a new version with zero changes from your existing and setup.py version requirements set to WTForms<3.0 - since we know for sure that the wtforms.ext.csrf changes will not work with wtforms3
2. Continue looking at what to do to move flask-wtf off wtforms.ext.csrf and instead using the class Meta based CSRF (since that will work with both wtforms 2 and 3)

[crast]

You can have and eat your cake (mostly) if you really want to:

you could have your __init__ continue to accept parameters like csrf_context csrf_enabled and such and forward them to meta['csrf_context'] and so on.

I mean, if you were crazy enough you could even solve the base class issue by doing a little bit of import detection magic - though it does mean your class has a different inheritance hierarchy on WTForms 1 - which is a bit nuts; I would recommend dropping support for WTForms 1.

[jeffwidman]

I'd love to see a PR put together around this, at least the compatibility changes (the flavor changes should be in a separate PR so they can be discussed separately).