-1000 Clicking a link is a lot simpler for most users - especially mobile/tablet users.
Have you ever tried to copy/paste on a mobile!
Do not change this to requiring copy/pasting a code!
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Thursday, 20 August, 2015 4:04:31 AM
Subject: Re: [keycloak-dev] Reset Password changes complete needs review
On 8/19/2015 9:10 PM, Bill Burke wrote:
> On 8/19/2015 2:01 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 18 August, 2015 4:53:44 PM
>>> Subject: Re: [keycloak-dev] Reset Password changes complete needs review
>>> On 8/18/2015 9:04 AM, Stian Thorgersen wrote:
>>>> Can you elaborate on what the benefits are of these changes? It seems
>>>> that we had something that was working just fine..
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>> Sent: Sunday, 16 August, 2015 11:26:54 PM
>>>>> Subject: [keycloak-dev] Reset Password changes complete needs
>>>>> Here's what I did, I can change things based on questions I
>>>>> other emails, but here's how it works.
>>>>> There's now the concept of "reset password" and a
different one "change
>>>>> * Reset password is something the user initiates. This will start
>>>>> Authentication Flow and success will login the user and bring them
>>>>> their application
>>>> I assume this is still through email - if so it's important that
>>>> only logged-in if the reset password link is opened in the same user
>>>> session as they initiated the reset password flow
>>> With the previous impl, if somebody as able to hack your email account,
>>> then they could bypass OTP entirely. Also previous implementation
>>> wasn't really compatible with auth SPI. There may be additional steps
>>> to reseting credentials beyond an email, i.e. entering in a code from an
>>> SMS message. We may also be reseting both OTP and Password. Finally,
>>> the update password required action had reset-password specific logic
>>> within it.
>>> Honestly, I'd prefer to switch exclusively to a temporary code as it
>>> makes everything much simpler to support: for us and for users wanting
>>> to write extensiosn. I don't think this is a big usability issue as
>>> Google requires entering a temporary code from an SMS message. Also,
>>> with the way it worked in 1.4, out-of-band email password reset would
>>> require relogging in which is actually more steps. Finally, links can
>>> be messed up by email readers sometimes if they are long enough, making
>>> them error prone.
>> -100 We should stick with link in email (and only link, not confuse users
>> by having multiple options), but why can't the link just include the same
> I also don't want multiple options. I want to get rid of the link
> I'm repeating myself, but, This is about your requirement of out-of-band
> link-clicks not logging in the user. That kind of flow is not
> compatible with the current Auth SPI and it requires hacks to required
> actions like Update Password to even work (which already exist). We're
> also going to have to make users aware of it and explain how to code for
> it if they are writing their own extension. It just makes things a lot
> more complicated if you are extending things.
> Finally, I don't like the link because at least for me, it opens a brand
> new tab and leaves the original still active. I also don't think the
> link is more user-friendly when the link is clicked in another browser.
> It is also possible the user is obtaining the link on a phone and that
> our update password screen will be a bit cramped there. Also, typing in
> a password from a phone is quite awkward and time consuming.
Furthermore, I don't like Verify Email either. It also should be
changed from link clicking to code entry. Like Reset Email, a new tab
is opened if you click the link. Like Reset Email, Verify email
requires you to completely relogin if the link is clicked in a different
JBoss, a division of Red Hat
keycloak-dev mailing list