Custom API key model w/o default `APIKey` table or admin

[bojanpy]

I would like to be able to inherit AbstractAPIKey directly from the model, without having to reference it via foreignkey, and also I would like django, to not create these tables at all:

class APIKey(AbstractAPIKey):
    pass

I would like to:
Inherit the Abstract class, without having to reference the model.

I would solve it by:
Not installing the app at all, if we migrated the code of the abstract base class away from models.py, we would be able to inherit without problems.

[florimondmanca]

Hi @virogenesis,

I am not sure I understood your question. You might need to expand on your use case with as many specifics as necessary.

But trying to understand, do you mean…

• Currently when installing the app, the API key model is registered by default, and you’d like that not to happen because you won’t be using this default model?
• You’d like to create custom API key models that aren’t immediately registered in migrations?

In the first case, does not installing the app suffice?

In the latter case, have you explored Meta.managed?

If False, no database table creation, modification, or deletion operations will be performed for this model. This is useful if the model represents an existing table or a database view that has been created by some other means.

[bojanpy]

Currently when installing the app, the API key model is registered by default, and you’d like that not to happen because you won’t be using this default model?

This is correct.

You’d like to create custom API key models that aren’t immediately registered in migrations?

This is false, I would just like to upgrade the model on top of the AbstractAPIKey.

In the first case, does not installing the app suffice?

It does not, because when I inherit from models.py if the app is not installed, I get a not installed error because the ApiKey gets imported:

RuntimeError: Model class rest_framework_api_key.models.APIKey doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

In the latter case, have you explored Meta.

Sure, I am aware of the managed False, can't see how it would help me :)

Hope that this clears up the question, thanks for the quick reply!

[florimondmanca]

@virogenesis Thanks. Do you have some realistic sample code to illustrate what you'd like to do? I'm trying to be helpful, but I'm still not sure what "upgrade the model on top of AbstractAPIKey" means. As I tried to communicate, I'd really need you to explain your full use case, with code, domain context, or whichever items seem necessary. At this point this is still very abstract to me — or maybe I'm just low on caffeine or something. 😆

[bojanpy]

Sure thing, I will test, fork, make a pull request, and i'm sure it will click.

PR's speak a thousand words :)

Thanks

[stpddream]

I have a similar need here. Would like to

• have my own CustomizedAPIKey that extends AbstractApiKey
• I don't need the default APIKey model and would like to remove the table from db & admin options as it will be very confusing.

Not installing the app causes a similar error as discussion above:
RuntimeError: Model class rest_framework_api_key.models.APIKey doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

Is there a way to do that?

Thanks!

[rpitonak]

Experiencing the same issue as @stpddream.

+1 for a feature that would allow replacing the default API key with a customized version.

[stpddream]

@florimondmanca

[bojanpy]

@rpitonak @stpddream

My idea was to move away the abstractModel into a different python file, so that including the AbstractModel wouldn't trigger django's models.py RuntimeError for app not installed.

It should be fairly easy to implement, but when I checked out the tests suite I think I will need to employ a bit of refactoring in order to test this functionality.

Basically if I remember correctly I was a bit confused with conftest configuring installed_apps, as well as settings.py in the test application. perhaps @florimondmanca can advise.

I would need a test case scenario where we use heroes project, with and without rest_framework_api_key installed.

[bojanpy]

oh, test_project is not a part of the test suite, it's only for documentation purposes.

[florimondmanca]

@virogenesis Right — the entire test_project is available for documentation/playground purposes, but we do use the heroes application as part of the test suite (which is why it's present in the INSTALLED_APPS there).

[florimondmanca]

So, if I understand correctly, the need here would be that in cases where one only uses custom models, and doesn't need the default APIKey, one would be able to not have that model in the database nor in the admin. Currently the table is created and the APIKey admin is registered, which is not desirable (although not blocking, right?) if we don't need them. Is this gist correct?

[rpitonak]

@florimondmanca Thank you for the write-up. This is 100% correct for my use case.

Currently the table is created and the APIKey admin is registered, which is not desirable (although not blocking, right?)

You are right, currently, it is possible to unregister the default APIKey from admin and ignore the created table (my current solution).

Please note, that I am willing to help with the implementation if needed.

[bojanpy]

question I may have is, will leaving out the entire app from installed_apps be sufficient for future features.

In case so then my approach will be sufficient, otherwise we may need to add some configuration flag that decides whether admin will get registered and model created in the database schema.

[florimondmanca]

I think there's a parallel to explore with django.contrib.auth's User model here, right?

There, we've got…

• Listing django.contrib.auth app is required to use any auth features
• Subclassing AbstractUser does register the resulting model in the database
• But they've got a AUTH_USER_MODEL config option which allows to swap the default User with a custom one.

… Should we be considering an API_KEY_MODEL setting? One could substitute it to point to myapp.APIKey, or set it to None to disable any default API key model registration altogether (e.g. if one has models in other apps).

Edit: turns out there's an unofficial project with guidelines on implementing swappable models — https://github.com/openwisp/django-swappable-models. It's much simpler for us since we don't ship models that link to APIKey via e.g. foreign keys.