3
Nmeri17
1y

#Suphle Rant 9: a tsunami on authenticators

I was approaching the finish line, slowly but surely. I had a rare ecstatic day after finding a long forgotten netlify app where I'd linked docs deployment to the repository. I didn't realise it was weighing down on me, the thought of how to do that. I just corrected some deprecated settings and saw the 93% finished work online. Everything suddenly made me happier that day

With half an appendix chapter to go, I decided to review an important class I stole from my old company for clues when I need to illustrate something involved using a semblance of a real world example (in the appendix, not abstract foo-bar passable for the docs)

It turns out, I hadn't implemented a functionality for restricting access to resources to only verified accounts. It just hasn't been required in the scheme of things. No matter, should be a piece of cake. I create a new middleware and it's done before I get to 50 lines. Then I try to update the documentation but to my surprise, user verification status turns out to be a subset of authentication locking. Instead of duplicating bindings for both authentication and verification, dev might as well use one middleware that checks for both and throws exceptions where appropriate.

BUT!

These aspects of the framework aren't middleware, at all. Call it poor design but I didn't envisage a situation where the indicators (authentication, path based authorisation and a 3rd one I don't recall), would perform behaviour deviating from the default. They were directly connected to their handlers and executed after within the final middleware. So there's no way to replace that default authentication scheme with one that additionally checks for verification status.

Whew

You aren't going to believe this. It may seem like I'm not serious and will never finish. I shut my system down for that day, even unsure how those indicators now have to refactored to work as middleware, their binding and detachment, considering route collections are composed down a trie

I'm mysteriously stronger the following day, draw up designs, draft a bunch of notes, roll my sleeves, and the tsunami began. Was surprisingly able to get most of previous middleware tests passing again before bed, with the exception of reshuffled classes. So I guess we can be optimistic that those other indicators won't cause more suffering or take us additional days off course

Comments
  • 0
    I still refuse to admit the initial design was a poor one. The reason middleware wasn't used from the onset is that I firmly believe they should only be used for functionality that directly affects either the request or response –csrf, for example. Content negotiation. Except for JWTs, authentication hardly has much to do with the request object and absolutely no correlation with the response renderers.

    So, even though I'm changing it, I still stand by my earlier decision. The only problem is that treating auth as a separate entity/component doesn't seem to scale well. There should be some sort of MIDDLE ground between framework-aware meta routing action, and flexibility. It's kind of poetic that these constructs are literally called MIDDLEWARE, but I'm not convinced they are that middle ground. Maybe, specialized classes bound with the same middleware-binding API, but strictly applicable to auth alone
  • 0
    @Nmeri17 I'm grateful to have redesigned these. The new api looks more compact /less tacky than the previous one. But more importantly, they are all consistent with each other, reducing cognitive load and enforcing that pattern originating from one common source

    Also found the middle ground I was looking for. It's dynamic ie any guard/sanitizer can be added or replace, bind to paths eg authentication via session, then evaluating account verification, then path based authorisation, or any other stack you please. Even the signature psr for middleware is a dead giveaway that these things aren't middleware
Add Comment