10:24 a.m.
Thanks Stian!
2016-07-19 9:10 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
Confirmed the issue. See
https://issues.jboss.org/browse/KEYCLOAK-3331.
We'll make sure this is included in RH SSO 7.0.1.
On 18 July 2016 at 15:55, Valerij Timofeev <valerij.timofeev(a)gmail.com>
wrote:
> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>