API key implementation

[LuomaJuha]

Still a work in progress, as the database entities needs to be converted into doctrine versions. Easier to open this for now as a draft pull request and finish this way.

• Adds an option to enable or enforce API keys for Rest API.
• API key generation happens in the users profile under developer settings.
• New database table api_key
• User can have n amount of API keys active at once.
• Each API key can be assigned a title for users clarity.
• If any of the users API keys are revoked, then user is blocked from generating new API keys or removing the blocked API key. This is to prevent misbehavior and usually and blocking a key should not happen often.
• API key usage is tracked by updating last_used column. The update interval is once every hour to avoid extra calls to the database.
• Adds next new classes:

• DeveloperSettingsController, general controller containing different actions for managing Developer settings related routing.
• DeveloperSettingsService, works as a bridge for accessing different developer settings related database entities
• ApiKeyService, service to manage api_key entities in the database
• ApiKey, entity class for an API key.
• HasEmailVerifiedAssertion, first assertion class which asserts that the user has a verified email in the database account.
• AuthorizationServiceFactory, Overrides the AuthorizationServices factory to allow setting Permissions and their related Assertions into the AuthorizationService

• New translation domain, Developer. Contains translations related to developer settings context.
• New database migration, 010-add-api-key-table.sql
• New configurations:

• permissionBehavior.ini
• new section for feature.Developer which contains option deniedTemplateBehavior to adjust the template rendered if user does not have proper permissions.
• permissions.ini
• New section for default.Developer. Default settings require the user must be logged in and have a verified Email in their account.
• Each section now supports adding assertion[] options. These assertions are then checked with each permission check if set.
• config.ini
• New section API_Keys, which contains the next options:
• mode: If set to 'disable' API keys are not used, default value. If set to 'enabled' API keys can be used and created but rest api requests do not require them. If set to 'enforced' using an API key with rest api is mandatory.
• token_salt: A random string of salt to add when generating API key tokens. This setting is required.
• header_field: In which header field should the API key token be provided in the request. This defaults to 'X-API-KEY'.
• key_limit: Controls how many API keys can a user have at once. Default value is 5.

Still needs to be implemented:

• Tests
• Translations?
• Simple API key usage logging?
• Allow API keys only be generated for users with a verified email?
• Wait until Doctrine has been merged and adjust pr
• Reconcile with laminas-log to monolog migration #4429 (if that PR gets merged before this one)
• Follow-up: add a console utility to remove expired tokens
• Follow-up: RateLimiter support for valid API key

Requires: #2233

[demiankatz]

@LuomaJuha, I only had a few minutes to start looking at this today, so I haven't done anything resembling a full review, but see below for a few initial thoughts and suggestions! I'll try to look at more of the code as time permits.

[LuomaJuha]

@demiankatz thanks for suggestions! I think i will add the ApiKeyController to avoid that. And this is still in progress at the moment as there is conversion to doctrine going and need tests + some small adjustments listed in the description :)

[LuomaJuha]

I'm opening this now for reviewing even though the doctrine which this uses is not yet merged.

[demiankatz]

@LuomaJuha, I haven't had time to read through everything yet, but see below for some initial comments based on my first partial review.

[demiankatz]

Thanks, @LuomaJuha! I finished my review just now; see below for a few more comments.

Note that I haven't looked closely at the AccessTokenService yet, since it's full of warnings related to Doctrine not being merged yet. I'll review it more carefully after Doctrine is in place (and when I can actually start doing some hands-on experimentation).

[demiankatz]

Thanks for the progress here, @LuomaJuha! Now that #2233 has been merged, you should be able to get this PR into a runnable state. Once you've done that, please request a new review from me and I'll start doing some hands-on testing. Also, see below for a very trivial formatting suggestion.

[demiankatz]

Here's the test failure -- once again, something to do with Doctrine entity annotations being mismatched with the actual database:

1) VuFindTest\Db\Service\DoctrineSchemaValidationTest::testSchemaValidation
Unexpected schema updates pending; first update: DROP INDEX api_key_token_idx ON api_key
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
+    0 => 'DROP INDEX api_key_token_idx ...pi_key'
+    1 => 'ALTER TABLE api_key CHANGE id...T NULL'
 )

/usr/local/vufind/module/VuFind/tests/integration-tests/src/VuFindTest/Db/Service/DoctrineSchemaValidationTest.php:89

[LuomaJuha]

@demiankatz Seems like i forgot that orm requires indexeses in the class also. Added it now.

[demiankatz]

Thanks for fixing the test. I'm just about out of time for today but will try to give this another look when I get online tomorrow. In the meantime, if you have a chance, please merge the dev branch into this PR -- since I recently added PHP 8.4 CI support, we need to merge that in to get the new set of required CI tasks to pass.

[demiankatz]

I noticed a few problems during review, but they're all simple and can be fixed by applying the suggestions below.

[demiankatz]

My hands-on testing revealed two minor things:

1.) I removed the confirm_delete translation string because it was unused elsewhere in VuFind... but it is needed here, so I have restored it.

2.) When I set this up, I forgot to generate salt and encountered an unintuitive error (had to look in logs to understand what was happening). I'm adding a "REQUIRED" label to the setting in config.ini to hopefully make it harder to overlook.

I'm going to apply my proposal and then approve and merge this. No further action required.

Thanks, @LuomaJuha!

[demiankatz]

One more last-minute addition: the new permission was not included in the summary of permissions in permissions.ini; I've inserted it.

[demiankatz]

Victory at last!

Dismissing with Ere's permission.