[undertow-dev] Howto create/configure a custom SessionManager and SessionConfig implementation?
Antoine Girard
antoine.girard at ymail.com
Wed Mar 29 15:42:32 EDT 2017
What spirit are you referring to?
If you are talking about the javadoc bit you quoted earlier, it simply says
that if you implement the *createSession *method, you must make sure to
first search for an existing *sessionId *in the exchange and use it in case
you find it. This is achieved by calling the *findSessionId *method on the
SessionConfig object.
This is exactly what is done in the redis example I sent earlier (
https://github.com/coat/undertow-redis-session/blob/
master/src/main/java/com/pedanticprogrammer/undertow/
RedisSessionManager.java line 69):
String sessionId = sessionConfig.findSessionId(serverExchange);
So to summarize, what you need to do:
- Create a Redis based session manager (following the above example)
- Set it up in your servlet Deployment via a *SessionManagerFactory*.
You do not even have to care about a *SessionConfig*.
Since you are using the servlet api with undertow, a *SessionCookieConfigImpl
*(it implements *SessionConfig*) will be created automatically for you when
the *ServletContext *is created.
That's it!
Cheers,
Antoine
On Wed, Mar 29, 2017 at 8:04 PM, Eric B <ebenzacar at gmail.com> wrote:
> Agreed, but what calls that createSession() method?
>
> From what I can tell looking at the code, it's the ioundertow.servlet.spec.
> ServletContextImpl.getSession(ServletContextImpl, HttpServerExchange,
> boolean) which calls the createSession() method, getting the SessionConfig
> object from the SessionCookieConfig object, which is instantiated in the
> constructor:
>
> public ServletContextImpl(final ServletContainer servletContainer,
> final Deployment deployment) {
> this.servletContainer = servletContainer;
> this.deployment = deployment;
> this.deploymentInfo = deployment.getDeploymentInfo();
> * sessionCookieConfig = new SessionCookieConfigImpl(this);*
> sessionCookieConfig.setPath(deploymentInfo.getContextPath());
>
> ...
> ...
>
> }
>
>
>
> public HttpSessionImpl getSession(final ServletContextImpl
> originalServletContext, final HttpServerExchange exchange, boolean create) {
>
> SessionConfig c = originalServletContext.getSessionConfig();
> ...
> ...
> ...
> ...
>
> final Session newSession = sessionManager.createSession(exchange,
> c);
> httpSession = SecurityActions.forSession(newSession,
> this, true);
> exchange.putAttachment(sessionAttachmentKey, httpSession);
> }
> }
> return httpSession;
> }
>
>
>
> So like I said, I can override the behaviour, but then I am not adhering
> to the spirit of the Manager which specifies that it must defer calls to
> the SessionConfig object.
>
> Thanks,
>
> Eric
>
> On Wed, Mar 29, 2017 at 10:05 AM, Antoine Girard <antoine.girard at ymail.com
> > wrote:
>
>> The SessionManager#createSession() method takes a SessionConfig as second
>> argument.
>> I don't understand what more do you need!
>>
>> Cheers,
>> Antoine
>>
>> On Wed, Mar 29, 2017 at 3:55 PM, Eric B <ebenzacar at gmail.com> wrote:
>>
>>> I'm not actually trying to reusue the SessionCookieConfigImpl. But in
>>> the SessionManager javadoc, it clearly states that:
>>>
>>> * As part of session creation the session manager MUST attempt to
>>> retrieve the {@link SessionCookieConfig} from
>>> * the {@link HttpServerExchange} and use it to set the session cookie.
>>> The frees up the session manager from
>>> * needing to know details of the cookie configuration. When
>>> invalidating a session the session manager MUST
>>> * also use this to clear the session cookie.
>>>
>>> So while I can create my own SessionManager that completely ignores the
>>> SessionConfig object, as per the SessionManager javadocs, the manager must
>>> attempt to retrieve the SessionConfig object from the exchange to set the
>>> session cookie. I am just trying to fulfill the SessionManager
>>> requirements.
>>>
>>> But there is missing documentation indicating how/where one can specify
>>> the SessionCookieConfig implementation that I want undertow to use. I
>>> would like undertow to use my own custom implementation.
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>> On Mar 29, 2017 9:35 AM, "Bill O'Neil" <bill at dartalley.com> wrote:
>>>
>>>> What exactly will you gain from reusing SessionConfig if you are going
>>>> to hack around a lot of it? If not much then just write your own handler
>>>> that handles the cookies and talking to Redis it might be less work then
>>>> customizing and hacking around SessionConfig.
>>>>
>>>> On Wed, Mar 29, 2017 at 9:01 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>
>>>>> Agreed, but I want to use my own SessionConfig implementation in which
>>>>> the Sessionid is stored in a different cookie structure then the default
>>>>> implementation.
>>>>>
>>>>> I was looking for something that allows me to specify the
>>>>> SessionConfig implementation I want undertow to use, but can't find that
>>>>> config option anywhere.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>>
>>>>> On Mar 29, 2017 8:44 AM, "Antoine Girard" <antoine.girard at ymail.com>
>>>>> wrote:
>>>>>
>>>>> A SessionConfig is just an interface for the SessionManager to
>>>>> retrieve the session ID.
>>>>> You do want to store session IDs in cookies, is that correct?
>>>>> In that case, simply use the default SessionCookieConfig:
>>>>> https://github.com/undertow-io/undertow/blob/master/core/src
>>>>> /main/java/io/undertow/server/session/SessionCookieConfig.java
>>>>>
>>>>> Cheers,
>>>>> Antoine
>>>>>
>>>>>
>>>>> On Wed, Mar 29, 2017 at 2:19 PM, Eric B <ebenzacar at gmail.com> wrote:
>>>>>
>>>>>> Thanks for the link; that is definitely going to be a big help for
>>>>>> the redis bridge.
>>>>>>
>>>>>> But I'm still unclear as to the "right" way to use/define my own
>>>>>> SessionConfig implementation. In the link you sent, they instantiate the
>>>>>> RedisManager with the existing SessionConfig object, and use whatever
>>>>>> undertow passes in the parameters.
>>>>>>
>>>>>> As I mentioned in my earlier post, I suspect I can hack around it
>>>>>> using the SessionConfigWrapper but that does not seem to respect the spirit
>>>>>> or intent of the wrapper, so I'm trying to figure out if there is
>>>>>> another/better way to do this.
>>>>>>
>>>>>> Or is the only solution to completely ignore the SessionConfig object
>>>>>> and build my solution independent of it? But then it will not respect the
>>>>>> contract of the SessionManager to retrieve the Sessionid from the SC object
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>> On Mar 29, 2017 8:00 AM, "Antoine Girard" <antoine.girard at ymail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi Eric,
>>>>>>
>>>>>> Unfortunately I cannot share that code as it's company property.
>>>>>> As far as I can remember, it was really easy. I used the java redis
>>>>>> library: Jedis
>>>>>> Oh, and look what I found:
>>>>>> https://github.com/coat/undertow-redis-session/blob/master/s
>>>>>> rc/main/java/com/pedanticprogrammer/undertow/RedisSessionManager.java
>>>>>>
>>>>>> That's a good starting point, if not the complete solution right
>>>>>> there.
>>>>>>
>>>>>> Cheers,
>>>>>> Antoine
>>>>>>
>>>>>> On Wed, Mar 29, 2017 at 1:48 PM, Eric B <ebenzacar at gmail.com> wrote:
>>>>>>
>>>>>>> Antoine,
>>>>>>>
>>>>>>> That's exactly where I am heading too. Is there any chance you
>>>>>>> still have our can share the code you used to do that?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>> On Mar 29, 2017 7:24 AM, "Antoine Girard" <antoine.girard at ymailcom
>>>>>>> <antoine.girard at ymail.com>> wrote:
>>>>>>>
>>>>>>>> I did a similar thing once: persisting sessions into a Redis data
>>>>>>>> store
>>>>>>>> My starting point was the InMemorySessionManager.
>>>>>>>>
>>>>>>>> Good luck to you!
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Antoine
>>>>>>>>
>>>>>>>> On Wed, Mar 29, 2017 at 1:09 PM, Eric B <ebenzacar at gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> From my understanding, I was thinking/planning to create my own
>>>>>>>>> SessionManager to handle the Session loading. And from the docs, it
>>>>>>>>> indicates that the SessionManager must delegate retrieving the sessionId to
>>>>>>>>> the SessionConfig object
>>>>>>>>>
>>>>>>>>> Am I heading down the wrong path? Is there an easier/another way
>>>>>>>>> to load/persist the session?
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Eric
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mar 29, 2017 7:01 AM, "Bill O'Neil" <bill at dartalleycom> wrote:
>>>>>>>>>
>>>>>>>>> If you want such a custom solution why not just use a cookie and
>>>>>>>>> ignore all of the SessionConfig code. You can write a handler
>>>>>>>>> that checks for the cookie and attaches your own custom session object to
>>>>>>>>> the exchange based on the cookie.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 28, 2017 at 9:41 PM, Eric B <ebenzacar at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Stuart,
>>>>>>>>>>
>>>>>>>>>> My goal is to actually replace the JSESSIONID cookie/mechanism
>>>>>>>>>> with my own mechanism. I am looking to use a JsonWebToken (JWT) to pass my
>>>>>>>>>> JSESSIONID to the application for a few different reasons:
>>>>>>>>>> 1) I would like to sign the JSESSIONID
>>>>>>>>>> 2) I would like to pass additional data along with the JSESSIONID
>>>>>>>>>> (ex: some auth claims)
>>>>>>>>>> 3) I want to be able to share this information between different
>>>>>>>>>> containers
>>>>>>>>>> 4) I want to pass a TTL with my token
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> At some level, I am trying to hack together an SSO solution
>>>>>>>>>> temporarily which would allow me to log into one container, and have some
>>>>>>>>>> credentials pass to another container. My issue is that both containers
>>>>>>>>>> are session based, and hence, need to be able to retrieve a session from a
>>>>>>>>>> sessionId. However, I also want to make sure that sessions don't expire -
>>>>>>>>>> that is if I am working in container 2, that my session in container 1
>>>>>>>>>> continues to live (if the user gets redirected back to container 1).
>>>>>>>>>>
>>>>>>>>>> So, in essence, I am looking to be able to extract my SessionId
>>>>>>>>>> from a mechanism other than the standard JSESSIONID cookie, but yet, still
>>>>>>>>>> continue to use the sessions seamlessly.
>>>>>>>>>>
>>>>>>>>>> I figure I could potentially hack around the design using the
>>>>>>>>>> SessionConfigWrapper in which I use the wrap() method to return my own
>>>>>>>>>> SessionConfig object, but that does not seem to fit in the spirit or design
>>>>>>>>>> of the wrapper.
>>>>>>>>>>
>>>>>>>>>> Is there another/better way to accomplish something like this?
>>>>>>>>>> Or is undertow designed with only the JSESSIONID cookie in mind? I did
>>>>>>>>>> notice the
>>>>>>>>>> SessionConfig.SessionCookieSource enum with value OTHER, but
>>>>>>>>>> cannot seem to see/figure out where that is used, or how to leverage that
>>>>>>>>>> setting. I looked through the ServletContextImpl class but only see the
>>>>>>>>>> SessionTrackingMode of COOKIE, SSL and URL available.
>>>>>>>>>>
>>>>>>>>>> Any help/insight would be greatly appreciated.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Eric
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Mar 28, 2017 at 7:57 PM, Stuart Douglas <
>>>>>>>>>> sdouglas at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Why do you need a custom SessionConfig? In general Servlet will
>>>>>>>>>>> use
>>>>>>>>>>> its own SessionConfig that matches the configuration of the
>>>>>>>>>>> deployed
>>>>>>>>>>> application (generally just using a JSESSIONID cookie, unless it
>>>>>>>>>>> has
>>>>>>>>>>> been customized).
>>>>>>>>>>>
>>>>>>>>>>> Stuart
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Mar 28, 2017 at 2:19 PM, Eric B <ebenzacar at gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>> > I've been trying to figure out how to build my own custom
>>>>>>>>>>> SessionManager to
>>>>>>>>>>> > push my sessions into Redis with a custom SessionConfig
>>>>>>>>>>> implementation, but
>>>>>>>>>>> > am having trouble finding any documentation to that extent.
>>>>>>>>>>> >
>>>>>>>>>>> > For the SesisonManager, I've read that I need to:
>>>>>>>>>>> >
>>>>>>>>>>> > Develop SessionManager which implements
>>>>>>>>>>> > io.undertow.server.session.SessionManager
>>>>>>>>>>> > Develop SessionManagerFactory which implements
>>>>>>>>>>> > io.undertow.servlet.api.SessionManagerFactory
>>>>>>>>>>> > Develop startup extension which implements
>>>>>>>>>>> > io.undertow.servlet.ServletExtension, and in
>>>>>>>>>>> handleDeployment(Deployment)
>>>>>>>>>>> > method change sessionManagerFactory with new
>>>>>>>>>>> SessionManagerFactory.
>>>>>>>>>>> > Register new ServletExtension by adding
>>>>>>>>>>> > ../META-INF/services/io.undertow.servlet.ServletExtension
>>>>>>>>>>> file (file should
>>>>>>>>>>> > contain the name of new ServletExtension. for example
>>>>>>>>>>> > com.my.utils.StartupExtension)
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > But I can't seem to find anything that indicates how to
>>>>>>>>>>> provide my own
>>>>>>>>>>> > SessionConfig implementation. How do I register a custom
>>>>>>>>>>> SessionConfig
>>>>>>>>>>> > implementation? Is there any documentation to that extent?
>>>>>>>>>>> >
>>>>>>>>>>> > Are there any examples that can show me how to create my own
>>>>>>>>>>> SessionManager
>>>>>>>>>>> > and SessionConfig object?
>>>>>>>>>>> >
>>>>>>>>>>> > Thanks,
>>>>>>>>>>> >
>>>>>>>>>>> > Eric
>>>>>>>>>>> >
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > undertow-dev mailing list
>>>>>>>>>>> > undertow-dev at lists.jboss.org
>>>>>>>>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> undertow-dev mailing list
>>>>>>>>>> undertow-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> undertow-dev mailing list
>>>>>>>>> undertow-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170329/84e39c5e/attachment-0001.html
More information about the undertow-dev
mailing list