<div dir="ltr">Confirmed the issue. See <a href="https://issues.jboss.org/browse/KEYCLOAK-3331">https://issues.jboss.org/browse/KEYCLOAK-3331</a>.<div><br></div><div>We&#39;ll make sure this is included in RH SSO 7.0.1.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 July 2016 at 15:55, Valerij Timofeev <span dir="ltr">&lt;<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div>Hi,<br><br>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.<br><br>Error on the page: JBWEB000065: HTTP Status 400<br>Warning in server.log: 14:04:42,979 WARN  [org.keycloak.adapters.OAuthRequestAuthenticator] (ajp-/0.0.0.0:8009-5)  No state cookie<br><br></div><div></div><div>Navigating to a protected resource (after the error occurs) loads expected web application page: this means that the user is already logged in.<br></div><div><br></div>The test web applicationhas been generated in Eclipse using maven <b>jboss-javaee6-webapp-ear-blank--archetaype 7.1.3 Final</b> archetype.<b><br><br></b></div>Have anybody tested KEYCLOAK-1014 issue in similar setup?<br><br>1) protected web application is running on another application server than Keyclok and another web domain<b> </b>(Apache, mod_jk)<br>2) RH SSO 7 is configured in root context (no /auth context)<br></div><br></div>Should we continue this dicussion here or should I submit a RH support case instead?<br><br></div>Kind regards<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">Valerij Timofeev<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-07-15 17:03 GMT+02:00 Valerij Timofeev <span dir="ltr">&lt;<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I&#39;ve figred out exact condition when descibed scenario fails for us:<br><br></div>1) it does not work in combination with our legacy web application (built on RH/JBoss Seam 2)<br>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<br><br></div>Are there any known general issues with Seam 2 or JSF web applications protected by Keycloak?<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-15 15:17 GMT+02:00 Valerij Timofeev <span dir="ltr">&lt;<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>I&#39;ve just quickly tested in RH SSO 7.0: it works!<br></div>The only thing we have to do now is to test thoroughly and roll out it in production :-)<br><br></div>Thank you very much for your quick assistance!<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-15 13:15 GMT+02:00 Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 15 July 2016 at 13:14, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just checked and I&#39;m not able to reproduce this issue.<div><br></div><div>I clicked on reset password in one browser, copied the link and opened it in a new incognito session. Worked just fine.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 15 July 2016 at 12:22, Valerij Timofeev <span dir="ltr">&lt;<a href="mailto:valerij.timofeev@gmail.com" target="_blank">valerij.timofeev@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div>Hi,<br><br></div>our customers are experiencing problems in situations where resetting password is started in one web browser and accomplished in another one.<br>This scenario occurs if a user surfs with one kind of web browser, but an email application opens password reset link in another one.<br><br>I suppose that the root cause is the same like the documented in KEYCLOAK-1014 one.<br><br>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.<br></div></div></div><div><br></div>Kind regards<span><font color="#888888"><br></font></span></div><span><font color="#888888">Valerij Timofeev<br><div><div><div><div><h1><br></h1></div></div></div></div></font></span></div>
<br></div></div>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>