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&gt; 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 >

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&gt;: > 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&gt; 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&gt; >> 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 >>> >> >> >

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&gt;: > 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&gt;: > >> 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&gt; 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&gt; >>> 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 >>>> >>> >>> >> >

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&gt; 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&gt;: > >> 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&gt; >> : >> >>> 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&gt;: >>> >>>> 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&gt; >>>> 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&gt; 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 >>>>>> >>>>> >>>>> >>>> >>> >> >