[b8] master token fix

[luceos]

Changes proposed in this pull request:

Two issues covered in this PR:

• Fixes the master token not working. The id column on the api_keys table is no longer used for the token strings. We introduced the key column for that. The AuthenticateWithHeader middleware now uses that.
• The api_keys column now has an user_id column, this allows generating a token forced for a specific user. In order to adhere to that while still allowing full admin use, the middleware no longer requires a ; userId= part to see whether an ApiKey is available. In addition it now applies a touched at date in the last_activity_at column the same way the AccessToken works.

Reviewers should focus on:

Is this okay? Any security complications we can see in the PR?
Do we need a follow up issue to clean up the code duplication with ApiKey and AccessToken?

I think this needs a test too.. At least confirming the bare functionality of master tokens work because I believe it's a very strong feature used by integrations..

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run php vendor/bin/phpunit).

[franzliedke]

Can we get the bugfix without the new feature, please? I want the former now, but more time to think about the latter.

[luceos]

Not adopting that code will mean that an Api Key created connected to a specific user can still authenticate for any user. That seems highly unintentional. And yes I can split it up, or we can rethink this logic and improve it for beta 9.

[tobyzerner]

I'm happy with this :)

[franzliedke]

In that case, tests would be awesome. 😁

[luceos]

Yes, give me a day to patch at least a test or two..

[luceos]

@flarum/core please weaponise your ocd goggles and give an opinion on the test. Let me give the reasoning first:

• I can't really use the existing Flarum Client we use internally, because it circumvents the middleware.
• I decided to push the request through the middleware so we can sensibly test the pipeline. The test injects a custom middleware instance using the (obsoleted) ConfigureMiddleware class, we'll need a replacement for that.
• The problem with resolving flarum.api.middleware is that the DispatchRoute middleware is appended immediately when resolved and there's no way to re-arrange the entries in the pipeline.

These tests took more time than I hoped, bear with me 👍

no longer valid due to tests

[tobyzerner]

The problem with resolving flarum.api.middleware is that the DispatchRoute middleware is appended immediately when resolved and there's no way to re-arrange the entries in the pipeline.

DispatchRoute is added to the pipe via afterResolving (see ForumServiceProvider) so using resolving should work fine?

[luceos]

Thanks for pointing that one out @tobscure, I assumed afterResolving was the only callback available.

Modified and patched.