Comments (12)
Thanks for your feedback @ScottHull!
The ability to have more control over the key generation would be great!
Would I be wrong to say that this needs solely stems from the fact that you're trying to use the prefix
to uniquely identify an API key?
Anyway, I suppose moving generate_key
to be a method of APIKeyManager
would fix this, and this probably is within the scope of #34. :-)
Edit: tracked in #44.
from djangorestframework-api-key.
the probability of a duplicate prefix is very low, but not 0.
I thought about it. We do enforce uniqueness of the prefix
(creating the API key would fail with a database error otherwise), but it's true that we don't make the .filter()
check.
The reason why is that the probability you mentioned is roughly N / 36^8 (36 = 26 letters + 10 digits), where N is the current number of API keys. Since 36^8 is about 3 trillion, this makes the probability of having two identical prefixes ridiculously small.
Besides, because of the current shape of the PK making the .filter()
check would be very slow and it could not be sped up via a DB index. This would be possible with the changes proposed for 2.0, though.
from djangorestframework-api-key.
Status update: all planned features for 1.3 are in and documented in dev/1.3
. 🎉 Releasing soon!
Edit: released in beta as 1.3.0.b0
. Will upgrade on my personal API first, wait a few days, and then release the definitive version.
from djangorestframework-api-key.
One thing I'm doing in my project is storing the user who generated the key and their organization. I was successful in doing this by subclassing the API key model and adding those attributes in the create_key method. The goal is to get the user's permissions within the organization from the API key.
Right now, I'm doing this by doing a database lookup on the prefix. However, there is the low chance of a duplicate being created between 2 users of 2 different organizations. I tried to increase the prefix size by making my own key generation method, but the generate_key method built in seems to be taking priority in the APIKeyManager model, so I can't change it.
The ability to have more control over the key generation would be great!
from djangorestframework-api-key.
Would I be wrong to say that this needs solely stems from the fact that you're trying to use the
prefix
to uniquely identify an API key?
Yes, that's correct @florimondmanca ! I not only need to authenticate the key, but then fetch additional permissions from the user the key is assigned to. My current scheme works and the probability of a duplicate prefix is very low, but not 0.
More custom control over the generate_key()
feature would help me assure that no duplicates of the prefix would be created. This could be done with a longer key and an objects.filter()
of the prefix to make sure that it isn't already attached to a user.
from djangorestframework-api-key.
Thank you for your insight!
Yes, the chance of two duplicates is extremely small and I can live with the risk in a production environment. I also spent a little bit of time to see if there were any functions in Django that returned the user with check_password()
, but there are none and that might be for security purposes.
In any case, I found the challenge of modifying your library for my project's needs to be interesting and I thought you might like to know of my use case for future updates. I'll be following your updates!
from djangorestframework-api-key.
I thought you might like to know of my use case for future updates.
Yes, it's always interesting to know how people use a library and more importantly what kind of hacks they come up with to overcome its shortcomings. ;-) Thanks!
from djangorestframework-api-key.
Will upgrade on my personal API first, wait a few days, and then release the definitive version.
Actually, since I don't know when I'll have the time to do this, maybe a public beta would be a good idea too.
The docs are ready — I can deploy them with a warning sign that everything related to customization is only available if explicitly installing ==1.3.0.b0
for now. :-) #57
Edit: published. Also now running in production on my blog's API. Will wait one or two days, and release final version. 👍
from djangorestframework-api-key.
1.3 released! https://pypi.org/project/djangorestframework-api-key/1.3.0/
from djangorestframework-api-key.
If 2.0 will contain migrations from 1.x (primary key field will be added in migration by transforming previous version of the model) DB-wise adaptation of existing projects should be trivial. Also it will be better to add new PK-column in one migration and drop old PK-column in anoother. FK to APIKey model is the issue in my project, I really would love to have INT primary key. So when 2.0 will be released I will add new columns to tables with FK to APIKey with migration that will be executed before the migration that will change PK in APIKey. Another migration will populate new FK fields with the INT FK to APIKey. This migration will be scheduled to take place before migration that will drop old PK column. Final migration will enforce NOT NULL constrains on the new FK columns where applicable and drop old FK columns in my project. This migration will also be scheduled to execute before the drop of the old PK column in APIKey.
from djangorestframework-api-key.
Thanks for sharing your plan @ssrebelious. It makes total sense to me, and will be very helpful when tackling the migration guide for 2.0. 👍
from djangorestframework-api-key.
Closing this as stale for now, as most of the contents in this roadmap are mostly correct, but I don't want to commit to anything particular at this point. (Besides, this roadmap has been literally idle for 6 months now.)
We might already be making good progress on allowing developers to retrieve API keys from within a view, e.g. via #93.
It would probably still be nice to reach out towards more meta features, such as "allow building views for managing API keys", i.e. "allow treating API keys as an API resource". I currently don't have time/energy to dig into this (I'm not even depending on this package myself anymore, to be honest!), so just trying to keep the scope tight for now. If/when that need for such features surfaces again, I'd be happy to provide guidance on anything that needs to be done to allow that.
from djangorestframework-api-key.
Related Issues (20)
- Getting 'Authentication credentials were not provided' in test project
- `KeyParser` should match `keyword` exactly HOT 1
- get_usable_keys() is empty
- APIKey generation in `CreateView` on a per-User basis?
- Best way to create and validate keys?
- Import not working
- Infinite loop with Django, MongoDB and Djongo with HasApiKey - Solved? HOT 1
- API_KEY_CUSTOM_HEADER not working HOT 2
- Migration file in `site-packages` folder for generating a custom API Key model HOT 1
- Is the API_KEY generated always unique? HOT 1
- IntegrityError using AbstractAPIKey
- Cannot authenticate with API key HOT 5
- API Key object pk/id created with api-key and hashed api key HOT 1
- About second to permission check HOT 1
- There is no clearly documented way to manually validate an API key HOT 2
- Customizing Api-Key name (documentation incorrect) HOT 1
- Hide DRF's browsable API page title when API Key is missing/invalid HOT 3
- Expired APIKey's are considered as valid APIKey
- Making invalid API Key raise 403 forbidden
- Declaring support for Django 5.0 (and Python 3.12)? HOT 1
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 djangorestframework-api-key.