[keycloak-dev] Theme resource provider - ability for custom authenticators to load additional templates

Stian Thorgersen sthorger at redhat.com
Thu Feb 8 14:06:26 EST 2018


OK, so now I've added support to load theme resources dynamically from a
hot deployment. All you need to do now to add templates and resources to a
hot deployed JAR is:

* Add templates to "theme-resources/templates" and resources inside
"theme-resources/resources"

See https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f
for an example.

Also, added support for hot deployment of themes. For that all you need to
do is:

* Add META-INF/keycloak-themes.json
* Add theme files to "theme"

See https://github.com/stianst/keycloak-experimental/tree/master/themes for
an example.

On 8 February 2018 at 12:30, Stian Thorgersen <sthorger at redhat.com> wrote:

> Damn you! I'm now looking at adding some magic touch to automatically
> detect theme-resources inside a deployment.
>
> On 8 February 2018 at 11:12, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> That may be cool, but think it's a fair amount of work to implement
>> something like that.
>>
>> I added a simpler approach with an abstract class
>> (AbstractClasspathThemeResourceProviderFactory). Now folks only need to
>> add bits to theme/resource and/or theme/templates,
>> extend AbstractClasspathThemeResourceProviderFactory and only implement
>> getId method. That's it.
>>
>> On 8 February 2018 at 10:37, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Good stuff.
>>>
>>> I wonder if we can improve usability even more. As people will need to
>>> implement ThemeResourceProvider. And IMO in 95% of cases, they will use
>>> templates from the JAR with their provider, so they would need to add some
>>> boilerplate code like this: https://github.com/stianst/key
>>> cloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/jav
>>> a/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22 .
>>>
>>> I am thinking if we can add default implementation of
>>> ThemeResourceProvider, which will scan classpath of the deployed provider
>>> archives automatically and find the resources from there? People won't need
>>> to implement their own ThemeResourceProvider, they will just need to add
>>> their templates into some directory like "src/main/resources/themes" or
>>> something like that. Maybe we can achieve this by adding ProviderEvent,
>>> which will be triggered on deploy/undeploy of any provider? Default
>>> ThemeResourceProvider will be able to listen to that and
>>> register/unregister classloaders of deployed providers automatically.
>>>
>>> WDYT?
>>> Marek
>>>
>>>
>>> On 06/02/18 20:03, Stian Thorgersen wrote:
>>>
>>>> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>>>>
>>>> Hi Stian, nice feature! Is it limited to login themes?
>>>>>
>>>>> Nah, it's a generic theme feature.
>>>>
>>>> Not sure I can see any use-cases other than custom providers that need
>>>> additional templates though. At the moment I can only think of
>>>> authenticators and required actions.
>>>>
>>>> Did you have any other use-cases in mind?
>>>>
>>>>
>>>> BTW the correct link is https://github.com/stianst/
>>>>> keycloak-experimental/tree/master/fido-u2f
>>>>>
>>>>> Also nice to hear that the work has finally started on U2F, it's
>>>>> indeed a
>>>>> must-have feature today. Is it slated for 4.0.0?
>>>>>
>>>>> Dmitry
>>>>>
>>>>> I was experimenting with a custom authenticator and found it annoying
>>>>> that
>>>>> I had to copy templates manually to the themes directory.
>>>>>
>>>>> To resolve this I added a Theme Resource Provider SPI.
>>>>>
>>>>> A theme resource provider can provide additional templates and/or
>>>>> resources
>>>>> alongside the custom authenticator.
>>>>>
>>>>> Themes are always searched first for templates and resources. Template
>>>>> resource providers are only searched if not found in themes. This is
>>>>> important as it allows a theme to override the templates and/or
>>>>> resources
>>>>> provided by a theme resource provider.
>>>>>
>>>>> The code is ready in the PR https://github.com/keycloak/ke
>>>>> ycloak/pull/4971
>>>>>
>>>>> For an example on how it's used take a look at
>>>>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>


More information about the keycloak-dev mailing list