[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 08:12:34 EDT 2017


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



More information about the keycloak-dev mailing list