Closed TimHollies closed 7 years ago
Replacing the AuthenticationService is probably the best option here.
Your service names don't look quite right though: The service name for the authentication service should be Omeka\AuthenticationService
. There is no OmekaAuthenticationService
class, so I'm not sure what your intent is with that service name. It also shouldn't be necessary to specify an alias at all: the existing alias in the core service manager configuration should suffice.
Yes, it appears I was getting a bit confused with the whole class aliasing system. The following works to replace the built in authentication service with a custom factory which returns a different Zend\Authentication\AuthenticationService
.
return [
// Add this section:
'service_manager' => [
'factories' => [
'Omeka\AuthenticationService' => 'LDAP\Service\AuthenticationServiceFactory'
]
]
];
Thanks for your help :)
In Omeka 2 there is a filter called 'LoginAdapter' which allows plugins to override the default authentication system with another - such as replacing it with the Zend Framework LDAP adapter. This is very useful as it allows us to let academics use their institutional logins on the system.
Is there a system which can allow modules to extend the authentication system in Omeka S or are there any plans to add one? I have not been able to find any events that have similar functionality in the published list in the omeka-s-developer repository or through exploration of the code.
I have also tried using the dependency injection system to swap out the default authentication service factory with my new one (which currently is a copy/paste of the default one anyway) as follows:
But this throws an error
Unable to resolve service "Omeka\AuthenticationService" to a factory; are you certain you provided it during configuration?
. I've found I am able to use this technique to mock other classes, but it doesn't seem to work with the Authentication service.