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

[Stian Thorgersen]

I'm happy with a simple PR then to just change the methods you need to
protected.

We won't be able to look at any SPIs for 7.2 anyways unless you decided to
contribute it ;)

For the template selections. Are you picking different templates per-client
or different themes?

On 2 October 2017 at 14:12, Vlastimil Elias <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> wrote:
>
>> Hi,
>>
>> I was asked by Stian to post my proposal around
>> 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
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Vlastimil Elias
> Principal Software Engineer, Middleware Engineering Services
> Red Hat
>
>