Comments (11)
Itsdangerous is a separate library and has nothing to do with django. Definitely not going to add magic that kicks in if the library is used in a certain environment.
from itsdangerous.
It's not quite true that it has "nothing to do with Django". The API and much of the implementation is derived directly from Django's code. That's besides the point though.
I admit that that kind of magic might not be the best way to do it.
However, what about my alternative suggestion about being able to set a default secret key? It's quite inconvenient, if you happen to be using Django just for one example, to have to pass the same key everywhere you use a signer.
It's really a violation of DRY to not have such a feature. What are your thoughts? Should I open a different ticket for it, or do you want to change the title of this one?
from itsdangerous.
It's really a violation of DRY to not have such a feature.
The solution that the flask ecosystem has is to make bridge libraries (Flask-SQLAlchemy for isntance) that preconfigures the library for the framework.
from itsdangerous.
On an aside: the API and implementation of itsdangerous has nothing in common with Django anymore.
from itsdangerous.
I really don't think I should need a bridge library (which wouldn't be easy to implement anyways), in order to have a default key. This is a very general feature. I don't need to bridge itsdangerous with Django or anything specific, it's just a global default for a certain value. Such a feature would be very useful no matter what framework you're using.
It's very convenient to have a global secret key, and then these pseudo-salts for each specific use of signing. It's much better than having different secrets for each, and I think that itsdangerous should facilitate doing it that way.
from itsdangerous.
There is not going to be a magic default to pick a secret key. There is no sane way to find the secret key for the library by itself.
from itsdangerous.
I think perhaps you're misunderstanding my suggestion. Forget the magic config for Django idea. I just want the option to tell itsdangerous at the module level what secret key to use by default.
e.g.
import itsdangrous
itsdangerous.DEFAULT_SECRET = '...'
If I'm using Django:
from django.core.conf import settings
import itsdangerous
itsdangerou.DEFAULT_SECRET = settings.SECRET_KEY
from itsdangerous.
I am not going to add global state and monkey patching to my libraries. I have been arguing against this dangerous anti pattern for years :-)
Not going to happen.
from itsdangerous.
Well I won't try to tell you what to do with your own project, but what alternative do you recommend in order to keep things DRY?
from itsdangerous.
As mentioned the solution is to use framework style integration libraries. That's exactly what Flask extensions are doing.
from itsdangerous.
In my opinion, that is inelegant and overly complex in the extreme. We can leave it at that disagreement though, thanks for your time on this.
from itsdangerous.
Related Issues (20)
- pgAdmin4 broken using itsdangerous > 2.0.0a1 HOT 1
- base64encode should be injected as a dependency in Signer class HOT 1
- Outdated pip link HOT 2
- Different lenght of tokens from 0.26 to 2.0.1? HOT 4
- ImportError: cannot import name 'json' from 'itsdangerous' HOT 5
- Incompatibility with Flask 1.1.1 (cannot import name 'json' from 'itsdangerous') HOT 4
- ImportError: cannot import name 'json' from 'itsdangerous' HOT 2
- Migration guide for deprecated JSONWebSignatureSerializer HOT 2
- Document that itsdangerous does not follow semver HOT 2
- ImportError: cannot import name 'TimedJSONWebSignatureSerializer' from 'itsdangerous' HOT 2
- catch overflow error on 32bit platforms
- Support async
- Issue with importing TimedJSONWebSignatureSerializer when updating db with Flask. HOT 1
- TimedJSONWebSignatureSerializer HOT 1
- Consider making `Serializer` generic in `t.AnyStr` for type checking to avoid overly ambiguous return types HOT 6
- Last character of serialized/signed data not robust HOT 1
- deprecate `__version__`
- use of `hashlib.sha1` causes issue in FIPS build
- Support digest_size when using blake2s or blake2b HOT 1
- serializer_kwargs are missing in load_payload function
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 itsdangerous.