As discussed in one of the last dev meetings, old legacy API keys will no longer be supported in the next version. API tokens are a much more secure and flexible alternative, and migrating is just a matter or switching one for the other when sending the Authorization header.
Tasks:
- Remove the logic that checks for API keys on incoming requests (maybe rename methods/vars from api_key -> api_token for consistency as well)
- Remove the API key snippet and "Regenerate API key" button from the user profile templates
- Remove the endpoint used to regenerate the API key and the
user_generate_apikey action and auth function
- Remove
apikey from the user schema
- Update documentation to make sure API keys are no longer mentioned or used in examples
- Some tests rely on test users' API keys (like this one). This should be refactored to use a different auth method or to create an API token and use that instead.
I think for the next version it is fine to keep the model property and the database field and not add any migration to remove it, in case users want to use it for migrating.
As discussed in one of the last dev meetings, old legacy API keys will no longer be supported in the next version. API tokens are a much more secure and flexible alternative, and migrating is just a matter or switching one for the other when sending the
Authorizationheader.Tasks:
user_generate_apikeyaction and auth functionapikeyfrom the user schemaI think for the next version it is fine to keep the model property and the database field and not add any migration to remove it, in case users want to use it for migrating.