Authentication adapter and validator are the same.
The authentication service provides input to adapter, which validates the identity and returns a result.
With the proposed revision of Zend\Validator, we also have the ability to chain adapters and aggregate results which can be useful in Zend\Authentication. We could add these missing features to the Zend\Authentication component.
As adapters validate identity, they could be renamed to Validator or moved to Zend\Validator, which would make Zend\Authentication dependent on Zend\Validator ?
Currently, the content of Zend\Authentication\Result::identity is not clear if the result is not valid. Most of time, it returns null, but sometimes it returns an empty array, or the provided identity.
The documentation says two different things about this:
getIdentity() returns the identity of the authentication attempt.
$identity is the value representing the authenticated identity. This may be any PHP type; typically you will see a string username or token, or an object type specific to the application or login module you utilize. When the result represents a failure to authenticate, this will often be null; some systems will provide a default identity in such cases.
So, on authentication failure, should the getIdentity() method always return the identity of the authentication attempt, or can it return whatever it wants?
I think it should not return identity if the authentication fails, as this method is intended to provide identity to the storage on successful authentication.
To sum up, I would like the Zend\Authentication component to :
Defines a Result interface modeling the results of authentication; it would compose the identity validated which will be use in authentication storage (only if authentication succeeded, otherwise it throws an error or returns null), authentication status, and, if present, any authentication error messages.
Defines validators (adapters) which define a single validate() (authenticate()) method, accepting both a value and optional context, and return a Result instance.
Defines a ResultAggregate interface for aggregating several results, as is necessary in a ValidatorChain (AdapterChain); Result instances would be pushed upon an aggregate.
Authentication adapter and validator are the same. The authentication service provides input to adapter, which validates the identity and returns a result. With the proposed revision of Zend\Validator, we also have the ability to chain adapters and aggregate results which can be useful in Zend\Authentication. We could add these missing features to the Zend\Authentication component.
As adapters validate identity, they could be renamed to
Validatoror moved to Zend\Validator, which would make Zend\Authentication dependent on Zend\Validator ?Currently, the content of
Zend\Authentication\Result::identityis not clear if the result is not valid. Most of time, it returnsnull, but sometimes it returns an empty array, or the provided identity. The documentation says two different things about this:So, on authentication failure, should the
getIdentity()method always return the identity of the authentication attempt, or can it return whatever it wants? I think it should not return identity if the authentication fails, as this method is intended to provide identity to the storage on successful authentication.To sum up, I would like the Zend\Authentication component to :
Resultinterface modeling the results of authentication; it would compose the identity validated which will be use in authentication storage (only if authentication succeeded, otherwise it throws an error or returnsnull), authentication status, and, if present, any authentication error messages.validate()(authenticate()) method, accepting both a value and optional context, and return aResultinstance.ResultAggregateinterface for aggregating several results, as is necessary in aValidatorChain(AdapterChain);Resultinstances would be pushed upon an aggregate.What do you think of this proposal ?
Originally posted by @ghost at https://github.com/zendframework/zend-authentication/issues/32