[keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers
Vlastimil Elias
velias at redhat.com
Mon Oct 2 09:28:11 EDT 2017
Yet another SPI :-D Seriously, design right granularity of SPI's may be
tricky.
As I said, for me it looks like current FormProvider SPI is enough if
existing FreeMarker providers will be written in a manner to allow
simple partial extensibility. So use of protected fields and methods,
and use of template method pattern may help a lot. I'll try to prepare
PR in this manner and we will see.
Vl.
On 2.10.2017 14:51, Stian Thorgersen wrote:
>
>
> On 2 October 2017 at 14:41, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
> Hi,
>
>
> On 2.10.2017 14:32, Stian Thorgersen wrote:
>> I'm happy with a simple PR then to just change the methods you
>> need to protected.
>
> great, I'll try to prepare PR against master branch and send it
> (hopefully this week).
>
>>
>> We won't be able to look at any SPIs for 7.2 anyways unless you
>> decided to contribute it ;)
>
> :-D
>
>> For the template selections. Are you picking different templates
>> per-client or different themes?
>
> We select complete Theme per client in the code, using realm's
> default if nothing special is defined for the client.
>
>
> I reckon we can fairly easily add a ThemeSelectorSPI for that purpose.
>
>
> Vl.
>
>
>>
>> On 2 October 2017 at 14:12, Vlastimil Elias <velias at redhat.com
>> <mailto:velias at redhat.com>> wrote:
>>
>> Hi,
>>
>>
>> On 29.9.2017 13:30, Stian Thorgersen wrote:
>>> Making the required methods protected is a simple way to
>>> work around the issue, but bear in mind that the FreeMarker
>>> providers are likely to change in the future.
>>
>> I'm aware of a potential change of the FreeMarker providers
>> in the future. For now this is preferred way for me as we
>> also need to change mechanism of Template selection (based on
>> client), so we have to extend these providers anyway.
>>
>>>
>>> Another option could be to introduce an
>>> FreeMarkerAttributeProviderSPI, the current freemarker
>>> providers would call all available providers to allow them
>>> to add additional attributes. Something like:
>>>
>>> * registerAccountAttribute(FormContext..)
>>> * registerLoginAttribute(FormContext..)
>>>
>>> Where FormContext would have access to KeycloakSession,
>>> AuthenticationSession, etc..
>>>
>>> Slightly more work, but would be more future proof IMO.
>>
>> If you have a room to implement this SPI and make it stable
>> (and supported in RH-SSO ;-), then I'm not against it, it may
>> be very useful for most of custom extensions.
>> It is likely that we will get rid of template selection
>> mechanism in the future, so we should switch to this SPI if
>> it will be available.
>> Still some refactoring of FreeMarker providers may be
>> performed as part of this change to make them easily usable
>> for more complicated custom extensions ;-)
>>
>>
>> Thanks a lot
>> Vlastimil
>>
>>
>>>
>>> On 27 September 2017 at 15:20, Vlastimil Elias
>>> <velias at redhat.com <mailto:velias at redhat.com>> wrote:
>>>
>>> Hi,
>>>
>>> I was asked by Stian to post my proposal around
>>> https://issues.jboss.org/browse/KEYCLOAK-2671
>>> <https://issues.jboss.org/browse/KEYCLOAK-2671> to be
>>> discussed here with
>>> wider KC dev team.
>>>
>>> What we need is to pass some additional attributes into
>>> Login and
>>> Account freemarker templates as part of our extensions
>>> - eg. to
>>> configure client side validations for registration form
>>> based on actual
>>> authentication session. Other use case we need is
>>> selection of Theme
>>> based on calling client.
>>>
>>> There are already Login and Account Form providers which
>>> may be
>>> customized (they are SPI), only problem is that current
>>> Freemarker
>>> providers use private fields and methods, so it is hard
>>> to customize
>>> them (I have to copy complete code which is hardly
>>> maintainable during
>>> keycloak upgrades).
>>>
>>> I believe we should resolve the problem by small
>>> refactoring of existing
>>> FreeMarkerLoginProvider and FreeMarkerAccountProvider
>>> providers similar
>>> you already done in FreeMarkerEmailTemplateProvider. So
>>> things like:
>>>
>>> * change fields and methods from private to protected
>>> to allow
>>> use/override in subclasses
>>> * refactor some features to protected methods (eg.
>>> Template loading
>>> from template provider - again, you did it in
>>> FreeMarkerEmailTemplateProvider provider already) to
>>> allow override
>>> in subclasses
>>> * add one protected callback method called just before
>>> template and
>>> attributes are passed to the freemarker engine for
>>> the processing -
>>> this allow subclass simply add additional attributes
>>> to be passed
>>> into template
>>>
>>> Only bigger change (and blocker for one of our important
>>> features) is
>>> passing of current AuthenticationSessionModel to the
>>> LoginFormsProvider
>>> instance at all places where the form provider is
>>> called. This is really
>>> missing now to be able customize GUI based on current
>>> client and
>>> authentication flow needs.
>>>
>>> I don't think those are big changes, but they will make
>>> life of
>>> extension developers much easier.
>>>
>>> I believe I'm able to provide pull request for this
>>> change if no better
>>> solution will be found there by experienced KC dev team.
>>>
>>> Thanks a lot in advance for any comments to my proposal.
>>>
>>> Vlastimil
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer, Middleware Engineering Services
>>> Red Hat
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer, Middleware Engineering Services
> Red Hat
>
>
--
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat
More information about the keycloak-dev
mailing list