Proposal - change Security object to accept instances instead of classes

Core Security object now accepts classes for various logic - registration, login, etc

flask_security.Security(
        app=application,
        datastore=user_datastore,
        register_form=MyCustomUserRegistrationForm,
        confirm_register_form=MyCustomConfirmUserRegistrationForm,
        login_form=MyCustomLoginForm)

Passing custom logic as classes means we don’t have a chance to seed objects performing validation with arguments outside of what FlaskSecurity envisioned in constructors for base/reference classes.

Say that for whatever reason I need to run some logic against Redis service in my login form - maybe I need to check if user isn’t logged already from too many other machines because I run Netlifx and people are trying to share their accounts. I don’t see any non-hackish way of injecting redis service instance to validation performed by MyCustomLoginForm now.

If instead of classes, Security object would accept instances that need to comply with expected interface (say have validation(payload) function), then I can easily seed my object with whatever arguments I need to do my complex custom logic that FlaskSecurity never envisioned:

class MyCustomLoginForm

  def __init__(self, redis_service):

    self.redis_service = redis_service

  def validate(self, payload):

      # ...


flask_security.Security(
        app=application,
        datastore=user_datastore,
        ...
        login_form=MyCustomLoginForm(my_redis_service))

In short - if Flask Security was accepting objects instead of classes, we would have flexibility to construct objects as we want, which would help with implementing arbitrary validation logic. With current setup we don’t have this ability.

Or to phrase it a bit different: Flask Security doesn’t allow me to pass arbitrary data to my own validation logic. Well, why?

I understand this is quite a large change, but it’s a pattern I see over and over in various frameworks - ones that expect classes to configure them limit users in what they can do in hooks, while ones that accept instance give users much more freedom for complex logic in hooks. Does the proposal look reasonable to others? Or maybe there is already a clean method to achieve what I’m trying to do here that I don’t realize?

[kuba-lilz]

Using with app.test_request_context() I got my custom registration form builder to work 😃

[jwag956]

Ahh yes - forms really really want a request context - I was hoping to get away with an app context - but no luck. The answer is simply to do

with app.test_request_context():
  fi = MyLoginForm(xxxxx)

I have updated the PR and added a specific test for CSRF.