Refactor api.py functions into an object (PyJWT) #101
Conversation
|
I understand why you did it, but it feels ugly to me to have a Perhaps some nicer API can be devised? I don't really have inspiration TBH. |
|
Ironically, I called it We have state already with the existing ability to register algorithms. This change only makes it easier for us to have configurable options such as custom pluggable validators, etc. For instance, in some applications, somebody may want to accept only HMAC tokens in certain scenarios or only RSA tokens and this allows that sort of configuration without descending into argument hell when people execute the methods. For those who use the existing APIs, its really completely identical. They will use a singleton instance of the class with global state and won't know any different. The object is only instantiated once and works exactly like it does today if you call |
|
The alternative would be |
|
That's true. That is an option. However, it is sometimes one of the more tiring things in cryptography since you have to add the backend parameter to every call. In their case, it does make sense because you have the option of entirely different backends. I think its kind of argument overload for this situation, in my opinion. |
…lass. - Created a singleton instance to preserve jwt.encode, jwt.decode, jwt.register_algorithms existing public APIs - Renamed load and verify_signature to _load and _verify_signature since they are not part of the existing public API - Modified related tests to use PyJWT._load and PyJWT._verify_signature
- test_jwt.py has been renamed to test_api.py since it focuses entirely on api.py - A new test_jwt.py has been introduced that focuses exclusively on testing the public API. (Specifically, making sure that encode and decode still exist and function). This test can be extremely simple since the jwt.encode and jwt.decode functions are backed by PyJWT() which is tested elsewhere.
… parameter to the PyJWT constructor. Also, PyJWT now has a get_supported_algorithms() method that returns back valid values for 'alg'
Refactor api.py functions into an object (PyJWT)
|
Gotta add some of this to the README. |
I know this is a big PR but really, the changes are quite simple and the public API is 100% unchanged except that the PyJWT class is exposed as a public part of the API. I think this paves the way for us to make more extensibility improvements going forward.
This PR refactors the functions in api.py into a PyJWT object. Changing these into an object instead of standalone functions makes extensibility (pluggable components, algorithms, etc.) much easier to implement and also allows for non-global configuration changes to be made by the consumer. For instance, by creating two instances of the PyJWT class, a consumer could configure two instances with entirely different algorithm sets. This would be a huge challenge using the current API.
encode(),decode(),load(),verify_signature(), andregister_algorithm()have been moved into this class.load()andverify_signature()are private parts of the API so they have been namedPyJWT._load()andPyJWT.__verify_signature.encode(),decode(), andregister_algorithm()from this global objecttest_jwt.pyhas been renamed totest_api.pysince its tests focus onapi.pycode exclusively.test_jwt.pyhas been created to verify thatjwt.encodeandjwt.decodefunctions still work. (Since most tests focus on the behavior of the PyJWT class, this is primarily to make sure that our public APIs properly pass calls to the PyJWT global object)