[keycloak-dev] Simplifying realm model

[Bill Burke]

On 6/19/2015 5:05 AM, Stian Thorgersen wrote:
>
>
> ----- 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: Friday, 19 June, 2015 10:40:35 AM
>> Subject: Re: [keycloak-dev] Simplifying realm model
>>
>> To me, it doesn't look like very big issue.
>>
>> IMO realm model is quite small and doesn't contain gazillion of objects
>> like users or userSession models. Everything in realm model can be
>> edited just by admin users and I think that many deployments have just
>> very small number of admin users (if not just one).
>>
>> With respect to all of this, the probability of concurrent edit seems to
>> be corner case. Hence I hope we can handle optimistic locking in one
>> place in the code in model and maybe just throw an exception with
>> message for the admin to retry it himself? I wouldn't do any retry logic
>> directly in the code of all rest endpoints. The increased complexity of
>> the code doesn't worth to handle the corner case IMO.
>
> You're probably right.
>
> Thinking about it some more the way that the admin console works it's actually broken now anyways and changing it to what's proposed with an optimistic lock would be an improvement.
>
> Take the following scenario for instance:
>
> 1. Admin1 opens the realm login settings page
> 2. Admin2 opens the realm login settings page
> 3. Admin1 enables self-registration and saves it
> 4. Admin2 enables remember-me and saves it
>
> Both step 3 and step 4 submit the same realm representation. In step 4 the realm representation will have self-registration disabled and remember-me enabled. This will override the change made in step 3.
>
> Now the same scenario above if we had optimistic locking in place and had the version in the realm representation sent to the admin console we could at least give an error to admin2 instead of overriding changes done by admin1. That's an improvement IMO.
>

Lol that we already have this problem... :)

If we do this approach, we'll have to add a version property to all json 
docs.  the admin REST api has gotten quite large....

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