Roadmap about djangorestframework-api-key

[florimondmanca]

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.

[florimondmanca]

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.

[florimondmanca]

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.

[ScottHull]

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!

[ScottHull]

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.

[ScottHull]

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!

[florimondmanca]

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!

[florimondmanca]

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. 👍

[florimondmanca]

1.3 released! https://pypi.org/project/djangorestframework-api-key/1.3.0/

[ssrebelious]

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.

[florimondmanca]

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. 👍

[florimondmanca]

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.