Implement different session handler

[jumbojett]

Implement different session handler

[jumbojett]

Good question @citosid ! There's a simple reason. PHP session handlers can already be extended / customized for these type of use-cases. (http://php.net/manual/en/session.customhandler.php) Since our library focuses on minimalism, we try to avoid reinventing the wheel. Does this help?

[Ddog800]

I know this is an old issue, but it came up in my search for a similar solution a few days ago and I wasn't able to find much else around how to do this. I thought it might be useful for future devs to post what I ended up doing.

In my case, we had built a custom login provider for Laravel so that we can easily tie our web applications to our OIDC infrastructure, and we used this lovely Jumbojett client as a base dependency to handle the heavy lifting of OIDC operations. However, we also needed the client to use Laravel's session handling infrastructure so the application would control where/how sessions are stored, rather than allowing it to fallback to the global settings of the web server.

To do this, I ended up creating a new client class, which inherits the Jumbojett OpenIDConnectClient class. I then overrode the following methods from the base client class:

startSession()
getSessionKey($key)
setSessionKey($key, $value)
unsetSessionKey($key)
commitSession()
redirect($url)

For our needs in Laravel, startSession() and commitSession were left empty since those things are handled automatically by the framework and the rest were implemented using framework calls. I was very thankful that the last one, redirect(), was a discrete method since I needed to override that one as well. However, that may not be necessary for every use case.

The reason I needed to do so here was because Laravel persists newly set session data near the end of the request pipeline. Allowing the Jumbojett client to redirect on its own was prematurely halting the pipeline execution, preventing the session data from being written. I needed to use the redirect functionality of the framework to ensure the request pipeline completed properly before the redirect occurred.

Overall, this approach should work for many use cases, depending on your session handling needs. It's a lot cleaner since you don't have to concern yourself with forking the entire client project and keeping it in sync with upstream changes, and can instead leave it as is as a base dependency. Let's hear it for polymorphism!

[citosid]

Oh perfect! That is awesome. I did not know you could do that kind of thing.

I was thinking on forking this and add that logic... but since it is possible to do it with php itself already, that might be the way to go.

Thank you!

[jumbojett]

this system will be in the cloud, using containers and load balancers

... I'll add this piece of advice as well. Check out the following tutorial on how to setup Redis as a back-end for session handling. It should work with distributed containers and our library.
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-redis-server-as-a-session-handler-for-php-on-ubuntu-14-04