Hi Stian, nice feature! Is it limited to login themes?

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/keycloak/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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Oh and U2F will most likely land in U2F. Feedback on my experimental implementation would be great as well :) On 6 February 2018 at 20:03, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > > > On 6 February 2018 at 18:42, Dmitry Telegin <mitya(a)cargosoft.ru&gt; 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/ keycloak/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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 6 February 2018 at 18:42, Dmitry Telegin <mitya(a)cargosoft.ru&gt; 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/keycloak/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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; 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(a)cargosoft.ru&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >

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(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:sthorger@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(a)redhat.com <mailto:mposolda@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/keycloak-experimental/blob/master/fido-u2f/u2f... <https://github.com/stianst/keycloak-experimental/blob/master/fido-u2f/u2f... . 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(a)cargosoft.ru <mailto:mitya@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/keycloak/pull/4971 <https://github.com/keycloak/keycloak/pull/4971> For an example on how it's used take a look at https://github.com/stianst/keycloak-experimental/tree/master/u2f <https://github.com/stianst/keycloak-experimental/tree/master/u2f>;. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>