Hi,
I was able to reproduce the problem in RH SSO 7.0 (rh-sso theme) in my
development environment with a pure CDI web application running on another
application server (EAP 6) in another web domain.
Error on the page: JBWEB000065: HTTP Status 400
Warning in server.log: 14:04:42,979 WARN
[org.keycloak.adapters.OAuthRequestAuthenticator] (ajp-/0.0.0.0:8009-5) No
state cookie
Navigating to a protected resource (after the error occurs) loads expected
web application page: this means that the user is already logged in.
The test web applicationhas been generated in Eclipse using maven
*jboss-javaee6-webapp-ear-blank--archetaype
7.1.3 Final* archetype.
Have anybody tested KEYCLOAK-1014 issue in similar setup?
1) protected web application is running on another application server than
Keyclok and another web domain (Apache, mod_jk)
2) RH SSO 7 is configured in root context (no /auth context)
Should we continue this dicussion here or should I submit a RH support case
instead?
Kind regards
Valerij Timofeev
2016-07-15 17:03 GMT+02:00 Valerij Timofeev <valerij.timofeev(a)gmail.com>:
I've figred out exact condition when descibed scenario fails for
us:
1) it does not work in combination with our legacy web application (built
on RH/JBoss Seam 2)
2) but it works in Keycloak 1.9.4 properly too if a user logins in into
the Account web application and then starts password reset process
Are there any known general issues with Seam 2 or JSF web applications
protected by Keycloak?
2016-07-15 15:17 GMT+02:00 Valerij Timofeev <valerij.timofeev(a)gmail.com>:
> I've just quickly tested in RH SSO 7.0: it works!
> The only thing we have to do now is to test thoroughly and roll out it in
> production :-)
>
> Thank you very much for your quick assistance!
>
> 2016-07-15 13:15 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
>
>> I tested with 2.0.0.Final though. Please check with 1.9.8.Final or RH
>> SSO 7.0. I believe there was some fixes around this at some point in 1.9.x.
>>
>> On 15 July 2016 at 13:14, Stian Thorgersen <sthorger(a)redhat.com> wrote:
>>
>>> Just checked and I'm not able to reproduce this issue.
>>>
>>> I clicked on reset password in one browser, copied the link and opened
>>> it in a new incognito session. Worked just fine.
>>>
>>> On 15 July 2016 at 12:22, Valerij Timofeev
<valerij.timofeev(a)gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> our customers are experiencing problems in situations where resetting
>>>> password is started in one web browser and accomplished in another one.
>>>> This scenario occurs if a user surfs with one kind of web browser, but
>>>> an email application opens password reset link in another one.
>>>>
>>>> I suppose that the root cause is the same like the documented in
>>>> KEYCLOAK-1014 one.
>>>>
>>>> We run Keycloak 1.9.4 standalone servers in our production at the
>>>> moment, but already started to roll out RH SSO 7.0 in other stages. So a
>>>> bug fix should be scheduled for this version as well.
>>>>
>>>> Kind regards
>>>> Valerij Timofeev
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>
>>>
>>
>