6:56 p.m.
For the sake of completeness, here is the bug that actually was the
reason for my problems: https://issues.jboss.org/browse/UNDERTOW-350
Since my application was deployed to the root context, the path of the
session cookie was set to a wrong value.
A quick workaround is to set the path in a servlet context
listener(seems like web.xml config is not used, I'll file a bug for that
when I have some time) like that:
public class ConfigServletContextListener implements
ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
sc.setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE));
sc.getSessionCookieConfig().setPath("/");
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
}
}
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 02.01.2015 um 08:34 schrieb Stian Thorgersen:
----- Original Message -----
> From: "Christian Beikov" <christian.beikov(a)gmail.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 30 December, 2014 3:47:00 PM
> Subject: Re: [keycloak-dev] Access original session
>
> I am using the following versions:
>
> * Keycloak 1.0.4.Final
> * Wildfly 8.1.0.Final
>
> Also it doesn't respect the cookie settings of the web.xml. I tried to
> configure a different name for the cookie just to test it, but it didn't
> change. When navigating to "/whatever.xhtml" I suddenly get the
> configured cookie set.
> It seems as if the Keycloak adapters wrap the HttpServletRequest to
> expose a different session map when working with secured resources.
> Which demo are you talking about? I would love to try it out so that I
> can confirm if it has something to do with my setup or Keycloak.
Keycloak should just be using the underlying http session and not do anything special to
it. Do you have the same problem with HTTP basic?
The demo I'm referring to is the one that is bundled with the download, it's in
examples/preconfigured-demo
> Mit freundlichen Grüßen,
> ------------------------------------------------------------------------
> *Christian Beikov*
> Am 30.12.2014 um 13:59 schrieb Stian Thorgersen:
>> ----- Original Message -----
>>> From: "Christian Beikov" <christian.beikov(a)gmail.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 30 December, 2014 1:45:13 PM
>>> Subject: Re: [keycloak-dev] Access original session
>>>
>>> Seems like my question wasn't clear enough.
>>>
>>> I have the following config in my web.xml
>>>
>>> <security-constraint>
>>> <web-resource-collection>
>>> <web-resource-name>Protected</web-resource-name>
>>> <url-pattern>/protected/*</url-pattern>
>>> </web-resource-collection>
>>> <auth-constraint>
>>> <role-name>user</role-name>
>>> </auth-constraint>
>>> </security-constraint>
>>>
>>> <login-config>
>>> <auth-method>KEYCLOAK</auth-method>
>>> <realm-name>portfolio-webapp</realm-name>
>>> </login-config>
>>>
>>> <security-role>
>>> <role-name>user</role-name>
>>> </security-role>
>>>
>>> Now when I navigate to e.g. "/protected/index.xhtml" I get
redirected to
>>> the Keycloak login. Unfortunately, the cookie which is set by the
>>> Keycloak adapters after a succesful login, has the path
"/protected"
>>> set. When I navigate to "/whatever.xhtml" I obviously have no
access to
>>> the cookie since the browser doesn't send it.
>>>
>>> How am I supposed to access the logged in user outside of the protected
>>> area?
>>>
>>> The session cookie (assuming you're talking about JSESSIONID) should be
>>> set
>>> to the context-path of your WAR not a specific protected resource.
>>>
>>> Unfortunately I am experiencing that it is set to a different path.
>> Strange. I've just tried with our demo, which has a similar
>> security-constraint to yours, and it sets it to the context-path of the
>> WAR as expected.
>>
>> Keycloak doesn't set this cookie itself, that's sorted by the JEE
>> container. Which Keycloak version and JEE server are you using?
>>
>>> Is your protected resources in the same WAR as the unprotected resources?
>>>
>>> Yes, it's all in the same WAR.
>>>
>>> Mit freundlichen Grüßen,
>>> ------------------------------------------------------------------------
>>> *Christian Beikov*
>>> Am 30.12.2014 um 13:38 schrieb Stian Thorgersen:
>>>> The session cookie (assuming you're talking about JSESSIONID) should
be
>>>> set
>>>> to the context-path of your WAR not a specific protected resource. Is
>>>> your
>>>> protected resources in the same WAR as the unprotected resources?
>>>>
>>>> ----- Original Message -----
>>>>> From: "Christian Beikov"
<christian.beikov(a)gmail.com>
>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>> Sent: Sunday, 28 December, 2014 11:01:54 AM
>>>>> Subject: [keycloak-dev] Access original session
>>>>>
>>>>> Hello there!"
>>>>>
>>>>> I have an application that has protected resources on the pattern
>>>>> "/protected/*" and I receive a session cookie for the path
"/protected",
>>>>> which makes sense. Now my problem is, that I want the path of the
cookie
>>>>> to
>>>>> be "/" so I can access the user information even outside of
the
>>>>> protected
>>>>> resources.
>>>>> Since I think this might introduce some problems, the only other way
to
>>>>> realize that I could think of is, to get access to the underlying
>>>>> servlet
>>>>> session. Not only would that session have to be created properly,
which
>>>>> I
>>>>> am
>>>>> not sure is happening when browsing in the protected resources, I
would
>>>>> also
>>>>> need to access it on the server, so that I can save the currently
logged
>>>>> in
>>>>> user into it.
>>>>>
>>>>> Is there a possibility to access the servlet session within the
Keycloak
>>>>> context? If so, could you please share some code or point me to an
API?
>>>>> --
>>>>>
>>>>> Mit freundlichen Grüßen,
>>>>>
>>>>> Christian Beikov
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>