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

[Stian Thorgersen]

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/
> java/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
>>
>
>
>