Roadmap

Following up on discussions in #41, I’d like to expose to everyone ideas for the future of djangorestframework-api-key.

Project mission and summary

djangorestframework-api-key adds API key permissions to the Django REST Framework.

The current design allows to manage API keys within a given project. In the future, we want to provide better support for:

• Customized API keys (e.g. linking API keys to another model via a foreign key).
• Building API key management features (e.g. an API key management REST API serving a custom-made admin frontend, which involves views and serializers).

Timeline

Note: this timeline is updated as new versions are released. Only roadmap items for future releases are listed.

Current minor version: 1.4

v1.x:

• ~#29 Scopes~ - Post-poned

v2.0: exposing API keys in views.

• #61 (originally #40, a version of this is already in dev/2.0) Change PK to integer field.
• #48 Migration guide for integer PK field

Future of 1.x

Upgrading to 2.0 may require a significant amount of effort for users that have models linked to APIKey. The risk of creating an “upgrade wall” and separating users between 1.x and 2.0 is real IMO.

But I’m not sure whether supporting both versions, and backporting new 2.x features into 1.x (at least for a certain amount of time) is worth it. It induces extra maintenance work, and with a clear migration guide most users should be able to upgrade without too much pain, and without losing any data.

So the plan is to discontinue 1.x support once 2.0 is out.

All of this is very much open to discussion. Feel free to share your thoughts/questions/insights! 👍

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

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