AuthenticationManager needs interface and ::getProviderKeys

Hm, is there on other method that can be used?

I guess having a method that returns all providers is useful, not 100% if that is the right one, though.

If we make this method public we should probably add an AuthenticationManagerInterface as well?

An alternative implementation is to provide an alternative service which lets you access to data, which though is not needed on runtime per default,
but this feels too much of an overhead.

If we make it public, then let's also add some unit tests. There's an existing unit test class, see existing examples there on how to set up the authentication manager and add providers, create one with 3 or so providers with different weight, then make sure you get them in the correct order.

+++ b/core/lib/Drupal/Core/Authentication/AuthenticationManager.php
@@ -20,7 +20,7 @@
-class AuthenticationManager implements AuthenticationProviderInterface, AuthenticationProviderFilterInterface, AuthenticationProviderChallengeInterface {
+class AuthenticationManager implements AuthenticationManagerInterface, AuthenticationProviderInterface, AuthenticationProviderFilterInterface, AuthenticationProviderChallengeInterface {

So shouldn't the authentication manager interface extend all the other ones here?

#2286971: Remove dependency of current_user on request and authentication manager modified AuthenticationSubscriber in a way such that it is possible to use a bare AuthenticationProviderInterface as the authentication service. E.g.

  authentication:
    class: Drupal\basic_auth\Authentication\Provider\BasicAuth

We even could automatically eliminate AuthenticationManager for sites which only use one authentication method, e.g. in #2432585: Improve authentication manager service construction to support custom global service providers. Therefore it should not be assumed that the authentication service actually implements the AuthenticationManagerInterface.

+++ b/core/lib/Drupal/Core/Authentication/AuthenticationManagerInterface.php
@@ -0,0 +1,34 @@
+  /**
+   * List of provider keys.
+   *
+   * @return array
+   */

You need to document the @return

Fx

/**
 * Get the list of provider keys/
 *
 * @return array
 *   The list of provider keys
 */

I know it may seem a bit double, but this is how the coding standards / doxygen is.

+++ b/core/lib/Drupal/Core/Authentication/AuthenticationManagerInterface.php
@@ -0,0 +1,35 @@
+   *   The list of provider keys

I know it's small stuff, but comments has to end with a "." like in a sentence. You can use a code sniffer to detect this for you.

#13 Yeah, sorry my bad for being in a hurry.

Looks good to me :)

Re #11: I think that #2456283: AuthenticationManager::getSortedProviders is protected should not assume that the authentication service always has getProviderKeys.

How come the rest ui can't just get the authentication providers from the container?
I.e just add

      - { name: service_collector, tag: authentication_provider, call: addProvider }

to your service and implement an add provider method.

Fixed in #2432585: Improve authentication manager service construction to support custom global service providers. See #2456283-6: AuthenticationManager::getSortedProviders is protected for how this is supposed to work now.

I am co-maintainer of project Drupal Console (http://drupalconsole.com) and we have the same blocker as REST UI had in the past, Drupal Console used to have a command to enable Rest Resources listing the Authentication methods available to be used by a Rest Resource.

The solution provided by Rest UI module to overwrite the AddProvider function to build a list of Authentication methods available isn't an option for us because Drupal Console is not a module so we can't overwrite the service. For that reason we require a way to get the list of method available.

If there is a security issue in rollback function getSortedProviders to public again, please let me know to consider remove that command from Drupal Console.

We switched getSortedProviders() in #2286971: Remove dependency of current_user on request and authentication manager to protected because of the following reasons:

The authentication service is only required to implement AuthenticationProviderInterface. Usage of the authentication manager is optional, authentication also works if a site hard-codes the cookie authentication provider into the authentication service. Throughout core there is nothing which desires to access metadata about providers managed by the authentication manager, therefore we concluded that this metadata is private to the manager.

I see that this conclusion is not quite correct. In fact provider keys are kind of shared with the routing system. Also I see that it might be useful for other use-cases to retrieve metadata about the providers if the authentication manager is in use.

However, I do no think that we simply should revert the visibility of getSortedProviders(). Rather let's add a method which returns metadata records keyed by provider key, such that the result looks something like this:

$result = [
  'basic_auth' => [
    'service_id' => 'basic_auth.authentication.basic_auth',
    'priority' => 100,
    'global' => FALSE,
  ],
  'cookie' => [
    'service_id' => 'authentication.cookie',
    'priority' => 0,
    'global' => TRUE,
  ],
];

Another option would be to simply move the provider collector service from the REST UI module to the core REST module. After all it currently looks like this is where that information is needed.