Slim 4 and Auth Middleware: passing the username to the App

1

In my Slim 4 App I need to authenticate the user and I have a setup a Middleware.

It runs ans correctly refuses users that are not authenticated.

Now, I’d like to share the current username with the App and can’t find a way to do so.

The skeleton of my Authentication Middleware looks like this:

namespace App\Middleware;

class Authentication implements MiddlewareInterface
{

    public function __construct($app) {
        

    }

    public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface {
    ...
   }

and is added through

$app->add(new \App\MiddleWare\Authentication());

I’ve tried to pass $app to the Authentication's constructor, but I can’t find a way to write to the container $app->getContainer() gives me.

I guess I can use $_SESSION… but there must be a better way…

How can I get the Middleware to set values that one can then read from a controller?

2

You can add things to the request in the middleware and they will be available on the request in later middleware and your controllers etc.

public function process(Request $request, RequestHandler $handler): Response
{
    // Some auth thing where you check the user is valid

    // Add some user info to the request so it is available
    // to anything processing the request after this middleware
    $request = $request->withAttribute('auth_user', $user);

    return $handler->handle($request);
}
3

Thanks!

Yes, using the request looks better than the $_SESSION.

I’m still a beginner with Slim, but to me putting this kind of data in the container feels better.
Am I missing something?

I’ve searched around, and I did not find any example with Auth modules that store the current user somewhere: how do other people show the current user in the top right corner of the window? : - )

4

Listen to @drinkynet says and use a request as inter layer message/info/values porter.
What you suggest is not a container purpose.

5

The general idea as I understand it :slight_smile: is that the route handler processes a request (and optionally some arguments) to make a response. So everything you need to know to process the request should either be on it directly, or in some other way accessible to the handler. You can use middleware to add stuff to the request as it passes through, like info about the currently authenticated user. The request passes through all of the things, so its the way you can transport things form one middleware to the next, and on to the route handler.

The DI container essentially contains a bunch of strategies for building things automatically that your apps other components might need, so that they can be built on demand when needed.

1 Like
6

thanks @drinkynet for the reply.

it helps!

if i get it correctly:

  • everything that is specific to the request goes into the request (current user, …)
  • everything that is specific to the app is in the container (db, …)

that makes sense.

i will have a look at

and try to find the bits that i am still missing.

sadly, most example, tutorials and skeletons i’ve found:

  • slim changes much between releases and since most documentation is based on simple examples, it’s not easy to find the rationals behind the choices presented.
  • most examples stop when it gets interesting: how to connect the bits (like showing the authenticated user in a twig template)
  • every author have slightly different approaches and it’s hard to tell which one should be followed and which not.

i think that i should learn more about laravel: that might help : - )

7

i think that i should learn more about laravel…

A that moment you’ll realize getting into serious troubles :smiley: