3:34 a.m.
+1 for UserCapabilitiesProvider.
For LDAP, the implementation of UserCapabilitiesProvider will be able to
detect the read-only/read-write fields automatically based on the
configured mode for the provider and configured mappers (eg. if
particular attribute mapper is writable or read-only etc)
Marek
On 02/12/16 17:09, Bill Burke wrote:
I know it is far from ideal. I think it can be added on later.
Storage
providers could implement a UserCapabilitiesProvider interface which
returns an object that specifies which attributes, mappings, etc. are
readonly/writeable, etc.
On 12/2/16 10:36 AM, Stian Thorgersen wrote:
> Can we with confidence do this early in 3.x without having to change
> the user storage SPI? If so I've got no issue with postponing it to 3.x.
>
> On 2 December 2016 at 16:30, Stian Thorgersen <sthorger(a)redhat.com
> <mailto:sthorger@redhat.com>> wrote:
>
> That's far from ideal. Dealing with this through an exception is
> horrible. I've said several times that all we need at minimum is a
> way for a provider to tell Keycloak if it's read or read/write. A
> boolean is fine for now. Once we had that it would take an hour or
> two to do the UI work.
>
> On 2 December 2016 at 15:15, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> All we're going to be able to implement is better handling of
> the ReadOnlyException. I just don't have time to do UI work,
> it takes too long. As it is, many providers will be hybrid,
> that will be both read-only and writable depending on the
> attribute, role, credential type, or whatever. LDAP is a
> perfect example where attributes and role/group mappings can
> be read only or writable in the same deployment. So, anything
> more elegant will require reworking LDAP as well.
>
>
>
> On 12/1/16 5:59 AM, Stian Thorgersen wrote:
>
> We should solve the following issues for 2.5.0:
>
> https://issues.jboss.org/browse/KEYCLOAK-3060
> <https://issues.jboss.org/browse/KEYCLOAK-3060>
> https://issues.jboss.org/browse/KEYCLOAK-3613
> <https://issues.jboss.org/browse/KEYCLOAK-3613>
>
> The current behavior of showing a form and throwing an
> error is not very elegant and this should be resolved
> before as part of user storage SPI work.
>
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev