Added option to initialize with custom pwd_context

[ryanolson]

I added the option to initialized Flask-Security with a user defined pwd_context.

My primary motivation for this change was to enable the use of the same pwd_context with two separate login systems: Flask-Security and Flask-JWT.

Unfortunately, you can not just nic the extension's .pwd_context and use that in your Flask-JWT authorization handler, because Flask-Security salts the password with the utils.get_hmac function. Due to the salting outside of the pwd_context, you can not use the pwd_context outside of Flask-Security.

My changes allow for two things:

1. Using SECURITY_PASSWORD_NO_SALT=True and SECURITY_PASSWORD_SALT=None, you avoid the pre-salting of the password and then can use the extension's .pwd_context asis. Passlib generally does a good job at using randomized salts on each call to encrypt, but the user should be aware. This options requires that Flask-Security is initialized so you can use it's pwd_context

2. Using your own pwd_context passed via init_app(..., pwd_context=my_pwd_context), you can use my_pwd_context in two applications that share the same user model, where 1 application uses Flask-Security and the other solely uses Flask-JWT.

This help address some compatibility issues with Issue #215

[coveralls]

Coverage increased (+0.01%) when pulling b963272 on ryanolson:pwd_context into 6bdcd29 on mattupstate:develop.

[coveralls]

Coverage increased (+0.01%) when pulling f9ca323 on ryanolson:pwd_context into 6bdcd29 on mattupstate:develop.

[mattupstate]

I'm not sure I understand the problem here. You can simply use verify_password and/or verify_and_update_password methods from the flask_security.utils module in your Flask-JWT authentication handlers. There was never any compatibility issues described regarding the two extensions yet, either.

[ryanolson]

You can only use verify_password and verify_and_update_password if you have Flask-Security initialized.

I'm more interested the second case where you have an application that does not use Flask-Security, but you wish to share the same pwd_context with another application that uses Flask-Security.

Application A: Flask-JWT only
Application B: Flask-Security only

[mattupstate]

you can still initialize Flask-Security and not have it register all the views on your app:

Security(app, ..., register_blueprint=False)

Both apps would have to share the same database and same security configuration that is specific to password hashes.

I do realize that might not provide what you're looking for, either.

[ryanolson]

Thanks Matt. I guess your solution could work, but it adds a lot of extra dependencies to Application A that get initialized but never used. Perhaps, I'm being a bit of a purist ...

What I love about Flask-Security is that it is a very well thought out and complete frontend authentication system.

Currently the UserDatastore is standalone, meaning, I can use that in a Flask-JWT application without initializing Flask-Security.

This pull request is trying to something similar with pwd_context. Perhaps we should create a new UserAuthenication object which could be initialized with SECURITY_PASSWORD_HASH, and SECURITY_PASSWORD_SALT.

Thoughts?

[mattupstate]

Thanks for your explanation. I understand you're use case a bit more now. That said, I'm not sure I'm ready to patch this type of feature in just yet. I feel as if this use case might better be served with a larger design update. I've been thinking hard about how I might make Flask-Security more flexible in general a lot lately and this would definitely be something that would be part of it.

[ryanolson]

That's cool. I'm actually using your work-around initializing Flask-Security without register views. For my current use case that should suffice. Looking forward to more good stuff to come.