[keycloak-user] KEYCLOAK-1014 Reset password leads to 400 Bad Request - still unresolved?

[Valerij Timofeev]

Thanks Stian!

2016-07-19 9:10 GMT+02:00 Stian Thorgersen <sthorger at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160719/3687588a/attachment.html