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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user