[WIP] [BC BREAK] Refactor of authentication layer

[adamlundrigan]

Why?

In a recent project I aimed to build a ZfcUser-based app to be used in both console and API (Apigility) contexts, and the authentication layer in it's current form is not well suited for either.

• AuthenticationChainEvent internalizes a copy of the Request object
• Db auth adapter uses getPost to pull user input from AuthenticationChainEvent::$request [Unable to use ZfcUder from console due to Authentication\Adapter\Db using getPost on $request #541]
• Db auth adapter assumes it's working with a PHP session [Authentication adapter should not know anything about authentication storage #513 Session is started by this module even in CLI mode #518]
• Db auth adapter assumes it's working with Bcrypt (not as big a deal as the others)

All of the above necessitated a partial rewrite of the Db auth adapter for our particular use case. As a more permanent fix I'd like to suggest the PR'd modifications to the authentication layer for ZfcUser 2.x.

This code is in no way finished and still needs additional work (see TODO below). Please dissect at your leisure and insult/nitpick/praise/rewrite to your heart's content ;)

Overview of changes

V2

• AdapterChain now triggers some events:
  • attach
  • authenticate.pre
  • authenticate.success
  • authenticate.failure
• Added event listener to regenerate SID on authenticate.pre when Session storage is being used

V1

• Rewrote the AdapterChain functionality.
  • Now just a proxy to an internalized priority list of standard Authentication adapters.
• Removed knowledge of Storage from adapters, as storage is handled by AuthenticationService.
• TODOs / notes
  • AdapterChain no longer triggers any events. May be a good idea to put it back in.
  • Ability to perform tasks on logout from the adapter has been removed. Is this something people use?
  • Throw an exception (here) if there are no registered adapters?

V0

• Modified AuthenticationChainEvent to store identity and credential, instead of request
• Renamed storage and adapter classes from Db to Mapper, a more apt description of their inner workings.
• Adapter now takes a mapper, a mapper method name, and a credential processor (Zend\Crypt\Password\PasswordInterface)
• Split the SM factory into two: MapperUsernameFactory and MapperEmailFactory
• Storage now takes a mapper and a backing storage object (session by default)
• Rejigged the service manager initialization for storage and adapter
  • Both now have factories instead of implementing ServiceManagerAwareInterface
  • Added generic service aliases for both to make overriding the concrete implementation easier

TODO

• Does adapter need to know about storage? I'm leaning towards moving the read from / write to storage somewhere else...but it's not really of top necessity now that storage is decoupled from session. Done
• Regenerating the session ID was inbuilt to Db auth adapter. I've removed it, but it needs to be implemented somewhere else that makes more sense (event listener attached by session storage factory?) Added as an event listener automatically when Session storage is in use.
• Persisting the user's password hash if it has changed was removed from Db auth adapter. Is this something that's necessary~~, and if so where should we trigger it~~? We could autoregister an event listener on authenticate.success to handle this (Prototype here).
• Fix the tests. The exposed behaviours of the authentication layer haven't changed, but the method of instantiation and list of collaborators has changed for a number of classes. Done
• Use Zend\Authentication\Adapter\DbTable\CallbackCheckAdapter? Mapper adapter is now sufficiently simplified to negate this.

[adamlundrigan]

git seems to think I deleted the Db files and created new Mapper files....ugh

[Danielss89]

Awesome that you started refactor of the authentication system, i had that on my todo list too.
I want to move away from the way it is done now, by events, as it's a totally wrong usage of how events should be used.

[adamlundrigan]

👍 If you want to give me the gist of how you'd like to see it implemented I can take a stab at it.

[ojhaujjwal]

👍

[adamlundrigan]

@Danielss89 I took a stab at simplifying the AdapterChain stuff. Internally it now just stores a priority list of standard authentication adapters and iterates over them on authenticate(). That's obsoleted pretty much everything from the old AdapterChain setup.

[adamlundrigan]

Travis test failure due to 5.3.x incompatibility in a test class (use $this inside an anonymous function). What's the target ZF2 / PHP version for ZfcUser 2?

[Danielss89]

We aim for PHP version 5.5 and ZF 2.3

[Danielss89]

Btw. i will go though this, i just don't have time until next week :) Probably next weekend.

[adamlundrigan]

I've added a prototype implementation of rehashing a user's password when required. I'm not 100% convinced it's the right approach so I've stashed it in a separate branch: adamlundrigan@98fbc53

[Danielss89]

I'm going to look through code now and drop comments, haven't tested yet though.

[Danielss89]

Please expand function name, LastInFirstOut?

[adamlundrigan]

That would be Zend Framework's problem: https://github.com/zendframework/zf2/blob/master/library/Zend/Stdlib/PriorityList.php#L172

[Danielss89]

Hahahaha yeah ok :D

[adamlundrigan]

Stdlib is a bit of a mess in that regard. SplPriorityQueue and SplQueue are wrappers around the SPL classes to make them serializable. PriorityQueue uses Zend\Stdlib\SplPriorityQueue internally to get around SplPriorityQueue's destructive iterator, while PriorityList is an entirely standalone implementation. PriorityList with LIFO=false is functionally equivalent to PriorityQueue, just implemented differently. PriorityList with LIFO=true is technically a priority stack, but there is no PriorityStack in Stdlib. The only difference between PriorityStack and PriorityQueue is how they break priority ties. As far as I can tell it's all necessitated by odd behaviours in the Spl classes. And all of this has absolutely nothing to do with this PR, I just got off-track but I spent the time writing it so I might as well post it.

I'm going to try to sub in \SplPriorityQueue to see if it will work for this use case. If not, I'll sub in Zend\Stdlib\PriorityQueue which is equivalent to what I have currently but will cause no future head-scratching over isLIFO(false).

[nuxwin]

Also, see my answer here about IDEA for chained authentication adapters:

#321 (comment)