[keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers

[Vlastimil Elias]

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.

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