On 1/26/2015 12:12 PM, Michael Gerber wrote:
Am 26.01.2015 um 16:54 schrieb Bill Burke <bburke@redhat.com>:
On 1/26/2015 8:45 AM, Stian Thorgersen wrote:
----- Original Message -----
From: "Bill Burke" <bburke@redhat.com>
To: keycloak-dev@lists.jboss.org
Sent: Monday, January 26, 2015 2:27:30 PM
Subject: Re: [keycloak-dev] Rest password can cause cookie not found
Wouldn't this work?
1) store "state" of state cookie in user session.
2) embed user session and state of state cookie in URL
Of course this screws up your "shorter URL" crusade.
I'm not following - the problem isn't remembering the state variable in Keycloak, that's already sorted as we already store all the query params passed by the client in the client session (state, redirect_uri, etc). The problem is storing it on the adapter side.
I think I get it...
1. Send email
2. Close browser
3. Open browser
4. Click email link
5. Reset password
6. Redirect back to app
7. App barfs because of state cookie
Persistent state cookie sounds like cleanest and simplest solution. I
just worry we'll introduce different bugs, or if we're opening up some
kind of security hole. Maybe I'm just paranoid.
That doesn't work if the user uses two different browsers. This is the case in a lot of companies (at least in Switzerland :)) where the users are forced to use ie (default) but rather work with firefox.
Unless we extend the protocol, or don’t redirect from the email, I don’t see a fix.
If the password reset process would redirect without the code and state param, than the adapter would redirect back to the keycloak, and keycloak can authenticate the user with its identity cookie…
But I don’t know if that is ok with the protocol.