[keycloak-dev] Reset password and verify email links are to long

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 12:42:58 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> On 16.7.2014 12:54, Stian Thorgersen wrote:
> > This is probably what you've said already Bill, but just to make sure:
> >
> > 1. Associate the required information to create a token from an access code
> > with the user session (basically what's in AccessCodeEntry now)
> > 2. The code that is sent as the query param only contains id, session-id,
> > timestamp
> > 3. Once we receive a code to swap for a token we remove the information
> > added in 1 from the user session and use this to generate the token
> >
> > Couple questions:
> >
> > * Do we do this just for emails? or also for the code sent in login
> > redirects?
> I would personally do it for all to avoid the possibility of exchange
> same code for token multiple times.
> > * Do we really need session-id and timestamp, or isn't id enough?
> I think that session-id is needed to find associated session? As request
> for exchanging code to token doesn't have access to browser cookie, so
> the info should be associated with the code parameter itself? Maybe
> another option is that UserSessionProvider will allow to find associated
> session by codeId (something like method on UserSessionProvider like:
> 
> UserSessionModel getUserSessionByCode(RealmModel realm, String code);

Yep, I was assuming you'd use the "code id" to lookup the access code details including the user session.

> 
> > * Isn't this pretty much just going back to state-full TokenManager except
> > we're saving it in the UserSession instead of TokenManager itself?
> IMO UserSessionProvider has possibilities, which TokenManager didn't
> have. Like storing sessions either inMemory or in DB (and hence be
> cluster-aware), periodic removal of expired sessions to avoid memory
> leaks etc.

Yup, but instead of making TokenManager have those options we made it stateless instead. By doing this we're going back to it being state-full. Just pointing out the obvious really ;) 

> 
> Marek
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 11:34:39 AM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >> +1 to associate code with the UserSession and remove it once code is
> >> exchanged. This will also help to fix the issue we discussed before,
> >> that now it's possible to exchange same code multiple times, which is
> >> not in line with OAuth2 specs . Created
> >> https://issues.jboss.org/browse/KEYCLOAK-560 and linked with
> >> https://issues.jboss.org/browse/KEYCLOAK-542
> >>
> >> Marek
> >>
> >> On 16.7.2014 10:58, Stian Thorgersen wrote:
> >>> Are you talking about reducing the size of the code altogether or just
> >>> for
> >>> the email links?
> >>>
> >>> I was thinking about just saving the base64 encoded access-code with the
> >>> user session temporarily, then sending the the access code id (36 char
> >>> uuid as before) in the email. First time the user clicks on the link the
> >>> access code would be removed from the session, so this would also make
> >>> the
> >>> links a one-time-click thing.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 15 July, 2014 6:14:45 PM
> >>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >>>> long
> >>>>
> >>>>
> >>>>
> >>>> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
> >>>>>> If that's what you're saying +1.
> >>>>> Are you referring to option 1, storing the required info in the user
> >>>>> session temporarily? Not sure I understand the details about what
> >>>>> you're
> >>>>> proposing though.
> >>>>>
> >>>> Yes, option 1.  AccessCode should be associated with the user session.
> >>>> Appropriate state needs to be stored in the session as AccessCode
> >>>> currently saves a lot of stuff.
> >>>>
> >>>> Then the code only has to contain:
> >>>>
> >>>> id, session-id, timestamp
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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
> >>
> 
>