Session injection via constructor

Questions Mezzio
,
1

Hi all,

I am not a big fan of retrieving dependencies via Request attributes. I believe dependencies should be explicit.

So the big picture :

I have pet project called web.expressive which tries to integrate the dms with zend expressive. ( I don’t think dms was developed in mind for PSR-7 requests, so its api is a bit different. )

It has an IAuthSystem system which is injected to most of the places and controllers ( actions ) . The AuthSystem needs session to check if the user is logged in or not.

I was trying to integrate zend-expressive-session for the AuthSystem . I did integrated the same via constructor injections and not making use of the Middlewares of zend-expressive-session or zend-expressive-session-ext .

I know I am doing against what expressive is doing here. But I am interested to hear your feedback about the same.

This is what it is defined in container.

You can see the ServerRequestInterface , SessionPersistenceInterface is injected to LazySession .

I have a Session middleware

which is similar to the one in

but notable one is LazySession is injected via constructor.

Is there any drawbacks or making use of the same ? Or is there a different approach I can follow here making use of the same Middlewares of zend-expressive-session.

I have also been looking at how @enrico is doing this on zend-expressive-authentication prototype .

I can’t go along the way for the core interface is making use at multiple places .

The code is under session branch .

https://github.com/harikt/web.expressive/tree/session ( package )

https://github.com/harikt/dms-expressive-skeleton/tree/session ( demo )

Thank you for your valuable time.

If you have feedback I am interested to hear.

2

A session is part of the request scope (in PHP even more specifically so,
due to share-nothing process semantics), so the initial issue (having
session passed in at construct) is a problem on its own. It should be moved
to call-time parameters, or you can move all parameters (including the
request) to the constructor, and make it a request-scoped object.

That said, I don’t understand what you are asking, specifically.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

3

@ocramius So the question is why not allow users to inject Zend\Expressive\Session\SessionInterface into the SessionMiddleware

than creating an object LazySession

Which is only available via Request ?

Now the same SessionInterface object can be used any where via constructor injection . And the middleware can finally persist the session.

See the difference in Middleware implementations.

UPDATE : This will also be same for Flash and Csrf repos middlewares.

4

I am probably just not fully awake, but I only see
SessionPersistenceInterface in the last two examples.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

5

I send a PR with the changes https://github.com/zendframework/zend-expressive-session/pull/12 . May be you now see what is different than the SessionPersistenceInterface .

6

Can you give me an example how you are going to make use of this?

What I understand is you are saying to build the object on Middleware.

public function process(ServerRequestInterface $request, DelegateInterface $delegate)
{
     $auth = new HktAuthSystem($request);
}

If so this is not possible in the current design. There are multiple places where the IAuthSystem is injected on constructor.

7

I’ve noted my reservations with using SessionInterface as a service in the pull request you created, and also detailed there a potential solution for your problem that does not require having the session as a service.

1 Like