Comments (7)
I think it depends on if you want to share the same jwt_manager/callbacks, or if you want each app to have their own. I haven't built any applications using a factory pattern, so I couldn't say what the best practices for this is, it will probably depend on your use case. But here is an example of how you could do it both way:
Using a different jwt_manager for each app (you could make different callbacks in here, with if statements and various config settings, if that was required)
# application.py
create_app():
app = Flask(__name__)
jwt = JWTManager(app)
@jwt.expired_token_loader
def my_expired_token_callback():
return jsonify({
'status': 401,
'sub_status': 101,
'msg': 'The token has expired'
}), 20
Using the same JWT manager for each app
# application.py
from extensions import jwt_manager
create_app():
app = Flask(__name__)
jwt_manager.init_app(app)
return app
# extensions.py
jwt_manager = JWTManager()
@jwt_manager.expired_token_loader
def my_expired_token_callback():
return jsonify({
'status': 401,
'sub_status': 101,
'msg': 'The token has expired'
}), 20
You could even take it a step further and have a third (or any number of other) files that define callbacks. Functionally this would work the same as above, but depending on how your code is structured it may make more sense to organize it this way. It could look like:
# <whatever>.py
from extensions import jwt_manager
@jwt_manager.expired_token_loader
def my_expired_token_callback():
return jsonify({
'status': 401,
'sub_status': 101,
'msg': 'The token has expired'
}), 20
Hope this helps!
from flask-jwt-extended.
@vimalloc If I do it your suggested way with <jwt_callbacks.py/whatever.py>
... How will the app know when I use the application factory way? I'd still need to import it into the create_app
function correct?
from flask-jwt-extended.
Yes, the create_app()
function would look the same regardless if you are putting your callbacks in <whatever>.py
or extensions.py
.
Just to be clear, I'm not actually sure if having the callbacks in a separate <whatever>.py
file would be a good idea or not, it depends on how your code is organized. It is just another option that is available to you. The key here is having your create_app
function import the jwt_manager and call init_app
on it, and have another place outside of the create_app
function use the loader methods to register callbacks. That is assuming that you want all the applications created with the create_app
function to have the same jwt callback functions.
from flask-jwt-extended.
My assumption was that jwt_call_back handlers would all be the same, especially when it comes down to error handling.
Because I was thinking of how to organize it so my application.py
and extensions.py
doesn't appear to be too cluttered, I am thinking of using the <whatever>.py
to contain the callback.
But the issue is I'd still need import the callback via <whatever>.py
to register it.
Would this be the preferred way to keep code modular and clean? Or would you recommend that writing the callbacks inside extension is enough?
Also, this would probably be a good time to also discuss logging feature for error handling of the app. Since some callbacks lead to 404, or 400 bad requests. Would you consider in adding a logging mechanism for errors? Or would this be out of your scope?
Thanks!
from flask-jwt-extended.
Personally I think in most cases having callbacks inside extensions.py would be fine, but that really comes down to a choice in your application, so I don't want to say anything too concrete. Really, I think either way would work just fine.
As per logging, I think that is something that we could put into this code. I think it may make most sense to put some sane default logging in, and if you wanted anything more specific to override the callback functions (via the loader methods) and put your own logging statements in there. What kind of things would you specifically like to see logged?
I'm going to be pretty busy for the next week or so, so it may be a bit before I can properly look at these. If you need logging for now, I would recommend just overriding the various callback methods (via the loader functions) and add your logging in there.
Cheers!
from flask-jwt-extended.
I'm looking errorr handlers to display warnings and errors with invalid api usage. It is useful to slap a pdb statement into the error handler and go up the stack to see where errors are.
Definitely an error_handler_callback sort of method would do the trick. Or maybe even setup logging to 3rd party apps like sentry, rollbar... etc..
from flask-jwt-extended.
Moving the logging discussion into #17 and closing this one
from flask-jwt-extended.
Related Issues (20)
- Typing issue HOT 1
- TypeError: check_if_token_in_blacklist() takes 1 positional argument but 2 were given HOT 1
- No 401 on failure HOT 1
- 'JWT_HEADER_TYPE' is being set to "" but not reflecting. I mean I still have to pass 'Bearer <token>'
- Signature verification failed with just generated tokens HOT 1
- Unable to catch errors using flask @app.errorhandler HOT 2
- Implicit refresh with cookies: timeout does not remove JWT/CSRF cookies – was this expected? HOT 1
- How does the CSRF functionality work? HOT 2
- Decoding CSRF Token from cookies does not work HOT 1
- flask-jwt-extended, refresh token HOT 3
- RS512 not supported HOT 2
- Is option JWT_REFRESH_TOKEN_EXPIRES working? HOT 3
- ImportError: cannot import name 'DecodeError' from 'jwt' (/usr/local/lib/python3.10/dist-packages/jwt/__init__.py) HOT 1
- Documentation examples for double submit removed from latest documentation. HOT 5
- Minimum cryptography version is vulnerable to CVE HOT 1
- Multiple JWT_HEADER_TYPE options HOT 1
- DeprecationWarning: The '__version__' attribute is deprecated and will be removed in Flask 3.1 HOT 1
- Changing Default Behaviors in another file doesnt work with flask-restful HOT 1
- Collections Module Issue
- Flask-JWT-Extended always assuming token is a refresh token HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flask-jwt-extended.