BTW, you could expand on the AccessCodeEntry. These entries are going
to be wiped out anyways when the web application turns an access code
into an access token. We would have a low priority reaper (like per
second or even per minute/hour), but it will be really rare that this
state isn't cleaned up.
On 8/1/2013 11:45 AM, Stian Thorgersen wrote:
The social providers needs to save some state between a request and a
callback (client_id, state, etc.). I've come up with 3 alternatives of how to save
this state:
* In http session
* In a session cookie (encoded json)
* In-memory - this would require a flushing mechanism (if callback never happens, for
example user just closes browser)
I'm not able to convince myself which is the better (or least bad), so do you have
any thoughts?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com