[keycloak-dev] User actions

[Stian Thorgersen]

How about using multi-part emails, that way we can send both in same mail and mail client chooses which one to show?

I don't think the HTML message should be very fancy, but it will be able to just have a "click here" instead of a long ugly link.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 19 September, 2013 4:33:49 AM
> Subject: Re: [keycloak-dev] User actions
> 
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>