Incorrect provider ID

@pviquez@pabloviquez.com thanks, is this still valid?

Here's the tutorial: https://www.drupal.org/docs/drupal-apis/authentication-api/create-a-cust... →

You may prepare a MR but a maintainer should check if this fix is correct. I think you can call it whatever you want, it's just used as reference?

Changing this value might be a breaking change, because the value may already be referenced in modules like services!

Ok thb I don't think the assumption here is correct. It's inconsistent, but you can call it whatever you want. Guess this should be closed, as the cosmetic fix would be a BC.

Still an issue in 3.0.x?

This is definitely still the case, but as you already stated in #7 🐛 Incorrect provider ID Needs review , this will cause a BC through changing the provider_id. Not sure if that is worth it, or how to gracefully change that id?

@grevil: Interestingly core now supports deprecation and aliases for routes: https://www.drupal.org/node/3317784 → - That would be fabulous for services here. But doesn't exist.

Maybe just copy the service in 3.x and deprecate the old one textually by a comment?
And then in 4.x remove it?

I'm not against a new 4.x branch for that then, but first we should clean up 3.x finally.

The service name is correct, but the service tag "provider_id" is incorrect (services_api_key_auth vs. api_key_auth).

But that would still be a breaking change for routes, etc. using the incorrect provider_id, e.g.:

mymodule.secured_page:
  path: '/mymodule/secured-page'
  defaults:
    _controller: 'Drupal\mymodule\Controller\PageController::getPage'
  requirements:
    _permission: 'access content'
  options:
    _auth: [ 'api_key_auth' ] // Now will be services_api_key_auth

I guess we could simply give a hint in an update hook, that other routes, etc. using "api_key_auth" should now use "services_api_key_auth"?

I mean, this is still a BC, but not for the module itself, but for other modules using this module's service. Eventually a minor release containing the update hook would be enough? (Even if it isn't 100% semVer compatible)

Let's make that change, but in 4.x branch later!

Actually I am against changing the "provider_id", we should stick to the provider standards provided in https://www.drupal.org/docs/drupal-apis/authentication-api/create-a-cust... → .

I adjusted the service accordingly.

Nice, I'm fine with that!

Should we do trigger a container rebuild on update?

All done! I also added a deprecation notice on the authentication service, see https://git.drupalcode.org/project/services_api_key_auth/-/commit/f85e1e... @Anybody, I guess this would be enough? Please review!

Automatically closed - issue fixed for 2 weeks with no activity.