[keycloak-dev] User actions

[Bill Burke]

Should these emails be text rather than pretty HTML?

On 9/16/2013 5:34 PM, Gabriel Cardoso wrote:
> Hi Stian,
>
> With regards to the "Reset password" flow, will we send the password
> written in the email to the user? How long can the user use this
> temporary password?
>
> I know that some services do this, but the most common flow that I've
> seen in a quick benchmarking was an email with link that takes the user
> to a page to enter and save the new password (see images below).
>
> I just want to clarify this point before prototyping.
>
>
> Thanks,
> Gabriel
>
> On Sep 11, 2013, at 9:33 AM, Bill Burke wrote:
>
>>
>>
>> On 9/11/2013 8:27 AM, Bill Burke wrote:
>>>
>>>
>>> On 9/11/2013 8:24 AM, Stian Thorgersen wrote:
>>>> Unless someone else has already started to work on (or is very
>>>> interested) I plan to work on account workflows. This work includes:
>>>>
>>>> * Email verification
>>>> * Reset password
>>>> * Configure TOTP after registration if required by realm
>>>> * Marking user as requiring actions before they can login to
>>>> applications
>>>>
>>>> I've outlined a proposal on:
>>>>
>>>> https://github.com/keycloak/keycloak/wiki/User-Actions
>>>>
>>>> Finally, when an account is in the state of requiring actions (read
>>>> the above wiki page to understand what I'm talking about!) the user
>>>> should have access to the account management pages, but not to
>>>> applications themselves. I was thinking in this case the
>>>> accessCodeId could be passed as a query parameter, which would allow
>>>> the account management pages to verify that the user is logged in,
>>>> but at the same not enable SSO to applications (as the cookie isn't
>>>> set yet). An alternative I was thinking of was that the
>>>> SkeletonKeyToken could have the status added to it, but I don't like
>>>> that approach as that would require applications to check the
>>>> status. Any other suggestions?
>>>>
>>>
>>> Not sure you need to do that.  User has an "enabled" property.  If that
>>> is not good enough, we could add a enum state variable to it.  SSO/OAuth
>>> logins would ensure that the user was in the appropriate state and
>>> forward to the appropriate pages.  It needs to do this anyways.
>>>
>>
>> Sorry, disregard my previous email.  I read your blurb too quick.
>>
>> Yes, you would need to pass along the accessCodeId along to the account
>> management pages if an action is required.  Another option might be to
>> set a session cookie for the accessCode and destroying this cookie when
>> the browser is finally redirected back to the application.
>>
>> The application should not be aware of Keycloak auth server specifics,
>> so I don't think adding account state to the SkeletonKeyToken is a good
>> idea at the moment.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Gabriel Cardoso
> GateIn Portal | User Experience Designer
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com