4:58 a.m.
Hi Stian,
On 18 October 2016 at 21:57, Dmitry Telegin
<mitya(a)cargosoft.ru>
wrote:
> Hi Stian,
>
> I completely agree on the first point, this deserves a better
> solution. But knowing that it would require digging deep into the
> guts of KeyCloak, I just didn't dare :)
>
> I would see providers somehow registering their custom enum keys,
> either via API call or via callback, and KeyCloak would maintain
> the list of custom values per provider. ServerInfoAdminResource
> then could return a combined list of enum keys, both built-in and
> defined by providers. But I'm afraid that would require changes to
> API and/or interfaces. What do you think? How would you approach
> this problem yourself?
We have SPIs to make features pluggable so that's the way to go. We'd
probably want a AdminResourceTypeSpi and at the same time refactor
the current enum to use this.
I was thinking about SPIs, but to me the ResourceType use case seemed
too minor to deserve its own dedicated SPI. OTOH, it would look quite
natural as a part of more generic Admin Resource SPI. I remember it's
been on the list for a long time, then why not finally getting hands
dirty?
Please take a look at the BeerCloak example I've announced earlier in
the list. There, I've tried to collect all the techniques I've been
using up to the moment to develop ad-hoc admin resources. I think I've
got enough experience and understanding to do the whole Admin Resource
SPI thing (with hypothetical AdminResourceTypeSpi becoming a part of
it, along with roles handling, authorization, event logging etc.)
That's it, I'd like to volunteer to implement Admin Resource SPI, and
to do it right way ("well designed, generically usable and
documented").
Please let me know what do you think. If you greenlight this, I think
we'd start a new thread to discuss the design.
> And BTW, what's wrong with the second PR? The github comment seems
> a bit unclear, so could you please elaborate? It has completely
> different scope, though deals with the same feature. It's not about
> exposing anything via static methods, it's about making
> ResourceType extensible, following a well-defined pattern. I was
> sure that Marek supported it, and I've implemented it in accordance
> with his recommendations.
Seemed rather hacky to me, but maybe I'm mistaking something. Can you
show an example on how it would actually be used? I don't see how
you'd add additional types and how you'd actually use the resource
type not knowing what type it is. Seems all operations valid on an
enum becomes invalid in this case.
See beercloak.BeerResource::create and other methods. There are
commented-out lines that show how it could look like. But I don't think
it's much relevant now, since we may come up with completely different
design with Admin Resource SPI.
Cheers,
Dmitry