<html><body><div>Hi All,</div><div><br></div><div>I've seen that both bugs have the Fix Version 1.1.1.Final, that's great.</div><div>Do you already know the release date for this version?</div><div><br></div><div>Best</div><div>Michael</div><div><br></div><div>Am 02. Februar 2015 um 09:32 schrieb Michael Gerber <gerbermichi@me.com>:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div><br></div><div><br>Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian@redhat.com>:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content"><br><br>----- Original Message -----<br></span></span><blockquote class="quoted-plain-text" type="cite">From: "Michael Gerber" <<a href="mailto:gerbermichi@me.com" data-mce-href="mailto:gerbermichi@me.com">gerbermichi@me.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">To: "Stian Thorgersen" <<a href="mailto:stian@redhat.com" data-mce-href="mailto:stian@redhat.com">stian@redhat.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">Cc: "keycloak dev" <<a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>></blockquote><blockquote class="quoted-plain-text" type="cite">Sent: Sunday, 1 February, 2015 4:09:35 PM</blockquote><blockquote class="quoted-plain-text" type="cite">Subject: Re: [keycloak-dev] Looking for a workaround...</blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">I would look at the following scenario:</blockquote><blockquote class="quoted-plain-text" type="cite">A user starts with the login process and then takes a long break (15 mins or</blockquote><blockquote class="quoted-plain-text" type="cite">more) without locking his computer.</blockquote><span class="body-text-content"><span class="body-text-content"><br>Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?</span></span></div></div></blockquote><span> </span></div><div>Unfortunately, it isn't. We have got customers which use one computer for multiple users. And this users are used to logout from the application without closing the browser.</div><div>The new user then uses the same browser to login. And this action would lead to an error, which is for the user not understandable.</div><div><br><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content"><br><br></span></span><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">There are critical processes like password changes, which should definitely</blockquote><blockquote class="quoted-plain-text" type="cite">expires after a view minutes and others like authentication which does not</blockquote><blockquote class="quoted-plain-text" type="cite">matter if they don’t expire during this break.</blockquote><span class="body-text-content"><span class="body-text-content"><br>As above we need to improve the error page in this case. With a way back to the application as well.<br><br></span></span><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">critical actions:</blockquote><blockquote class="quoted-plain-text" type="cite">- OAUTH_GRANT</blockquote><blockquote class="quoted-plain-text" type="cite">- CODE_TO_TOKEN (already seperate)</blockquote><blockquote class="quoted-plain-text" type="cite">- VERIFY_EMAIL</blockquote><blockquote class="quoted-plain-text" type="cite">- RECOVER_PASSWORD</blockquote><blockquote class="quoted-plain-text" type="cite">- UPDATE_PROFILE</blockquote><blockquote class="quoted-plain-text" type="cite">- CONFIGURE_TOTP</blockquote><blockquote class="quoted-plain-text" type="cite">- UPDATE_PASSWORD</blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">non-critical actions:</blockquote><blockquote class="quoted-plain-text" type="cite">- AUTHENTICATE</blockquote><blockquote class="quoted-plain-text" type="cite">- SOCIAL_CALLBACK</blockquote><blockquote class="quoted-plain-text" type="cite"></blockquote><blockquote class="quoted-plain-text" type="cite">> Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <<a href="mailto:stian@redhat.com" data-mce-href="mailto:stian@redhat.com">stian@redhat.com</a>>:</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> What groups would you propose?</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> ----- Original Message -----</blockquote><blockquote class="quoted-plain-text" type="cite">>> From: "Michael Gerber" <<a href="mailto:gerbermichi@me.com" data-mce-href="mailto:gerbermichi@me.com">gerbermichi@me.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>> To: "Stian Thorgersen" <<a href="mailto:stian@redhat.com" data-mce-href="mailto:stian@redhat.com">stian@redhat.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>> Cc: "keycloak dev" <<a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>> Sent: Monday, 26 January, 2015 4:23:49 PM</blockquote><blockquote class="quoted-plain-text" type="cite">>> Subject: Re: [keycloak-dev] Looking for a workaround...</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>>> ----- Original Message -----</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> From: "Michael Gerber" <<a href="mailto:gerbermichi@me.com" data-mce-href="mailto:gerbermichi@me.com">gerbermichi@me.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> To: "Stian Thorgersen" <<a href="mailto:stian@redhat.com" data-mce-href="mailto:stian@redhat.com">stian@redhat.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Sent: Monday, January 26, 2015 2:10:59 PM</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Subject: Re: [keycloak-dev] Looking for a workaround...</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> ----- Original Message -----</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> From: "Michael Gerber" <<a href="mailto:gerbermichi@me.com" data-mce-href="mailto:gerbermichi@me.com">gerbermichi@me.com</a>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> To: <a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Sent: Monday, January 26, 2015 1:37:53 PM</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Subject: [keycloak-dev] Looking for a workaround...</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Hi all,</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> I receive a lot of bug reports from our test team because of the</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> following</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> two issues:</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> - Reset password leads to 400 Bad Request (</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> <a href="https://issues.jboss.org/browse/KEYCLOAK-1014" data-mce-href="https://issues.jboss.org/browse/KEYCLOAK-1014">https://issues.jboss.org/browse/KEYCLOAK-1014</a> )</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> This is a tricky one - we can't ignore the state variable as that would</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> make</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> it vulnerable.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> We could probably come up with an alternative way to generate and verify</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> state variable though. Could be a HMAC for example.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> So you would remove the state cookie?</blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>> It could potentially be a solution - I started a separate thread on</blockquote><blockquote class="quoted-plain-text" type="cite">>>> keycloak-dev to discuss this.</blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> - Login attempt after "Login user action lifespan" leads to "Invalid</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> username</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> or password." ( <a href="https://issues.jboss.org/browse/KEYCLOAK-1015" data-mce-href="https://issues.jboss.org/browse/KEYCLOAK-1015">https://issues.jboss.org/browse/KEYCLOAK-1015</a> )</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> I agree that the error message is not very good, but I disagree with</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> removing</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> the expiration. Why not increase it to say 30 min? That's probably a</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> more</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> sensible timeout for reset password as well.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> I prefer an expiration of 5 min for the password update process, but</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> thats</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> a</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> bit short for the authentication or password reset process.</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> I think the best solution would be different expiration times for the</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> different processes, wouldn't it?</blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>> Maybe - we do try to keep configuration options to a minimum as these</blockquote><blockquote class="quoted-plain-text" type="cite">>>> introduce complexity as well as potentials for bug/security issues.</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>> I totaly understand that.</blockquote><blockquote class="quoted-plain-text" type="cite">>> You have currently the following actions:</blockquote><blockquote class="quoted-plain-text" type="cite">>> OAUTH_GRANT,</blockquote><blockquote class="quoted-plain-text" type="cite">>> CODE_TO_TOKEN,</blockquote><blockquote class="quoted-plain-text" type="cite">>> VERIFY_EMAIL,</blockquote><blockquote class="quoted-plain-text" type="cite">>> UPDATE_PROFILE,</blockquote><blockquote class="quoted-plain-text" type="cite">>> CONFIGURE_TOTP,</blockquote><blockquote class="quoted-plain-text" type="cite">>> UPDATE_PASSWORD,</blockquote><blockquote class="quoted-plain-text" type="cite">>> RECOVER_PASSWORD,</blockquote><blockquote class="quoted-plain-text" type="cite">>> AUTHENTICATE,</blockquote><blockquote class="quoted-plain-text" type="cite">>> SOCIAL_CALLBACK</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>> And it doesn't make sense to have a different conffiguration for every</blockquote><blockquote class="quoted-plain-text" type="cite">>> one...</blockquote><blockquote class="quoted-plain-text" type="cite">>> But maybe we can group it into different groups?</blockquote><blockquote class="quoted-plain-text" type="cite">>></blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Do you have any good ideas for a workaround?</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Best</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> Michael</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> _______________________________________________</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> keycloak-dev mailing list</blockquote><blockquote class="quoted-plain-text" type="cite">>>>> <a href="mailto:keycloak-dev@lists.jboss.org" data-mce-href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>>></blockquote><blockquote class="quoted-plain-text" type="cite">>>>> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" data-mce-href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></blockquote><blockquote class="quoted-plain-text" type="cite">>>>></blockquote></div></div></blockquote></div></div></blockquote></div></body></html>