AuthenticationMiddleware: overview of version 2.0

[dreamingmind]

In the post Request Response Sequence Overview is a UML showing processes that wrap this more detailed look at the Authentication 2.0 middleware.

If your not familiar with a sequence diagram

• The boxes across the top represent class objects.
• The vertical dotted lines are the lifespan of the objects
• The vertical bars are methods and their lifespans
• Solid horizontal arrows are method calls
• Dotted horizontal arrows are method returns (mostly)

This shows, roughly, the three phase of the authentication process:

1. initializing the Authentication middleware (finishes at step 12)
2. authenticating the request (through step 19)
3. modifying the Request to reflect the results (through step 29)

More notes below the chart.

Steps 5-10 are pretty specific to my setup, but they stand as a good example of how you will configure multiple authenticators and identifiers that will be used sequentially later during authentication checks.

The class labeled ConcreteAuthenticatior represents the Authenticators loaded in steps 5-8. They will be tried in sequence unless one of them succeeds and returns through step 16. Each one will try all the configured Identifiers in sequence.

Of special interest to me was step 22 where any custom Identifier object you design gets put into play. Having an object with a little more knowledge than just the user record is quite handy.

[drtrppr]

You pointed me to this diagram in order to help to get the authentication clear (Authentication plugin: install & use).

It helps to see how the process proceeds step-by-step, that’s what’s meant for, that’s ok.

In order to get my questions answered, I have to map this diagram on the used CakePHP-files (for example, application.php etc.) to get an idea where at what place to change things to get the desired result. Because I’m a noob, I’ve no idea.

In case of my search to find how the get unauthenticated acces to ‘local:8765’, it’s in step 17 I guess? And now I have to figure out in what file to use what command. I’m not that familiar with UML, but is there a way to connect this diagram with how the steps are implemented?

(Typos in step 8 and in neughborhood step 17?).

[dreamingmind]

My meaning was not very clear.

I was responding to

@drtrppr

Haven’t searched yet, but there will be something to have done higher up in the controller-tree

The only ‘higher up’ for the middleware is in step 3 (when the middleware calls your src/Application.php method getAuthenticationService().

After that process is done, everything is out of your hands.

But you are right, the middleware code that will ultimately let through your ‘approved’ pages is down in that tan box.

[drtrppr]

Authentication plugin: install & use

I’ve always assumed it was my learning style. I do best with a global perspective first. Then I have a scene to fit all the details into. But the cake docs are presented in (what I think of as) a more traditional rule-list form. Rule-lists are the least effective way for me to learn anything. This is the reason I drew the UMLs. But I haven’t decided how much detail they should have to be a useful and maintainable part of the documentation. Less detail than I have included so for I’m sure.

I’v drawn a lot of diagrams, it’s my experience that it’s always about scope and purpose which determine the level of detail.

Scope in how it fits between existing diagrams, like for instance high level CakePHP at a Glance - 4.x and Middleware - 3.10 (even if these are not UML, how do these diagrams relate? Maybe some extra (UML)-diagrams needed, maybe it’s ok now?

Purpose in who’s the reader and what is s(he) looking for? Manager, NOOB, core-developer, debugger, student, programmer? All of them will need another level of detail.

And in the end? 99% of the diagrams were only used by myself to organize my thoughts, to get things clear to myself. Just to be able to discuss things with managers, analists, developers.