Was originally discussed here: http://lists.jboss.org/pipermail/keycloak-user/2016-January/004288.html And I asked the same question again here: http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html But feel free to keep bumping. It's a feature I'd like to see anyway ;-) Josh Cain Senior Software Applications Engineer, RHCE Red Hat North America jcain(a)redhat.com IRC: jcain On 01/15/2018 06:10 AM, eric.kapitza(a)web.de wrote: > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

I wonder how hard it would be to implement? On Mon, Jan 15, 2018 at 3:22 PM, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > I think that Freemarker theme (at least login theme) has access to > ClientBean through the "client" expression . So it's likely already > possible to do some hacking in the template itself and provide different > CSS according to the client used. Not very nice, but likely should be > somehow possible. > > Marek > > On 15/01/18 18:26, Josh Cain wrote: >> Was originally discussed here: >> http://lists.jboss.org/pipermail/keycloak-user/2016-January/004288.html >> >> And I asked the same question again here: >> http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html >> >> But feel free to keep bumping. It's a feature I'd like to see anyway ;-) >> >> Josh Cain >> Senior Software Applications Engineer, RHCE >> Red Hat North America >> jcain(a)redhat.com IRC: jcain >> >> On 01/15/2018 06:10 AM, eric.kapitza(a)web.de wrote: >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user

It makes sense to add two options: 1. Expose client attributes to theme. That would allow setting an attribute on a specific client or a client template to then have some conditions to provide variants within a theme. 2. Allow overriding theme in client and client template. No need to add something additional to themes as they can already be extended. We simply need to allow users to specify a different theme. In this case we may also want to add a ThemeSelectorSPI that would allow some custom logic to select the theme (could be based on headers for instance in the case of a mobile theme). On 16 January 2018 at 14:09, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > We can probably do some builtin support for clients into the themes > itself. Doing it properly may take few days. Depends if we want to > support that. AFAIR Stian didn't like that, but to me it makes sense > that some people want different look&feel based on client. > > For example template file can be lookup from the directory with the > clientId (EG. theme/my-theme/login/customer-portal/login.ftl ). If it > doesn't exists, then fallback to the current location without "clientId" > directory. Maybe something similar would be needed for the CSS files and > other resources. > > But for some very basic cases, people can probably already handle it by > add some "if" into the freemarker template itself and use different CSS > styles based on the client or something like this. > > Marek > > > On 16/01/18 00:09, Bill Burke wrote: >> I wonder how hard it would be to implement? >> >> On Mon, Jan 15, 2018 at 3:22 PM, Marek Posolda <mposolda(a)redhat.com&gt; > wrote: >>> I think that Freemarker theme (at least login theme) has access to >>> ClientBean through the "client" expression . So it's likely already >>> possible to do some hacking in the template itself and provide different >>> CSS according to the client used. Not very nice, but likely should be >>> somehow possible. >>> >>> Marek >>> >>> On 15/01/18 18:26, Josh Cain wrote: >>>> Was originally discussed here: >>>> http://lists.jboss.org/pipermail/keycloak-user/2016- > January/004288.html >>>> >>>> And I asked the same question again here: >>>> http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html >>>> >>>> But feel free to keep bumping. It's a feature I'd like to see anyway > ;-) >>>> >>>> Josh Cain >>>> Senior Software Applications Engineer, RHCE >>>> Red Hat North America >>>> jcain(a)redhat.com IRC: jcain >>>> >>>> On 01/15/2018 06:10 AM, eric.kapitza(a)web.de wrote: >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

I've started work on this as I needed a simple dev task to wake up ;) https://issues.jboss.org/browse/KEYCLOAK-3370 On 16 January 2018 at 17:06, Josh Cain <jcain(a)redhat.com&gt; wrote: > +1 for that solution, would make some of what we're looking to do in the > near future *way* cleaner! > > Josh Cain > Senior Software Applications Engineer, RHCE > Red Hat North America > jcain(a)redhat.com IRC: jcain > > On 01/16/2018 08:54 AM, Stian Thorgersen wrote: >> It makes sense to add two options: >> >> 1. Expose client attributes to theme. That would allow setting an > attribute >> on a specific client or a client template to then have some conditions to >> provide variants within a theme. >> 2. Allow overriding theme in client and client template. No need to add >> something additional to themes as they can already be extended. We simply >> need to allow users to specify a different theme. In this case we may > also >> want to add a ThemeSelectorSPI that would allow some custom logic to > select >> the theme (could be based on headers for instance in the case of a mobile >> theme). >> >> On 16 January 2018 at 14:09, Marek Posolda <mposolda(a)redhat.com&gt; wrote: >> >>> We can probably do some builtin support for clients into the themes >>> itself. Doing it properly may take few days. Depends if we want to >>> support that. AFAIR Stian didn't like that, but to me it makes sense >>> that some people want different look&feel based on client. >>> >>> For example template file can be lookup from the directory with the >>> clientId (EG. theme/my-theme/login/customer-portal/login.ftl ). If it >>> doesn't exists, then fallback to the current location without "clientId" >>> directory. Maybe something similar would be needed for the CSS files and >>> other resources. >>> >>> But for some very basic cases, people can probably already handle it by >>> add some "if" into the freemarker template itself and use different CSS >>> styles based on the client or something like this. >>> >>> Marek >>> >>> >>> On 16/01/18 00:09, Bill Burke wrote: >>>> I wonder how hard it would be to implement? >>>> >>>> On Mon, Jan 15, 2018 at 3:22 PM, Marek Posolda <mposolda(a)redhat.com&gt; >>> wrote: >>>>> I think that Freemarker theme (at least login theme) has access to >>>>> ClientBean through the "client" expression . So it's likely already >>>>> possible to do some hacking in the template itself and provide > different >>>>> CSS according to the client used. Not very nice, but likely should be >>>>> somehow possible. >>>>> >>>>> Marek >>>>> >>>>> On 15/01/18 18:26, Josh Cain wrote: >>>>>> Was originally discussed here: >>>>>> http://lists.jboss.org/pipermail/keycloak-user/2016- >>> January/004288.html >>>>>> And I asked the same question again here: >>>>>> http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html >>>>>> >>>>>> But feel free to keep bumping. It's a feature I'd like to see anyway >>> ;-) >>>>>> Josh Cain >>>>>> Senior Software Applications Engineer, RHCE >>>>>> Red Hat North America >>>>>> jcain(a)redhat.com IRC: jcain >>>>>> >>>>>> On 01/15/2018 06:10 AM, eric.kapitza(a)web.de wrote: >>>>>>> _______________________________________________ >>>>>>> keycloak-user mailing list >>>>>>> keycloak-user(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Added a public ThemeSelectorSPI [1] that allows adding custom logic for selecting what theme to use. The default implementation is very simple at the moment [2]. It simply looks for the realm setting and fallbacks to the default if not set. Changing the selector is a global thing and there is no mechanism to configure a separate selector for a realm. That's something we could consider adding later if needed. The question is should we provide the ability to set the theme per-client or is that actually quite cumbersome to use? There could be hundreds of clients.

[1] https://github.com/stianst/keycloak/tree/KEYCLOAK-6289 [2] https://github.com/stianst/keycloak/blob/KEYCLOAK-6289/services/src/main/... On 17 January 2018 at 08:54, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: +1 to handle on the client. Seems to be better than handle in the theme itself. Marek On 17/01/18 08:19, Stian Thorgersen wrote: I've started work on this as I needed a simple dev task to wake up ;) https://issues.jboss.org/browse/KEYCLOAK-3370 <https://issues.jboss.org/browse/KEYCLOAK-3370> On 16 January 2018 at 17:06, Josh Cain <jcain(a)redhat.com <mailto:jcain@redhat.com>> wrote: +1 for that solution, would make some of what we're looking to do in the near future *way* cleaner! Josh Cain Senior Software Applications Engineer, RHCE Red Hat North America jcain(a)redhat.com <mailto:jcain@redhat.com> IRC: jcain On 01/16/2018 08:54 AM, Stian Thorgersen wrote: It makes sense to add two options: 1. Expose client attributes to theme. That would allow setting an attribute on a specific client or a client template to then have some conditions to provide variants within a theme. 2. Allow overriding theme in client and client template. No need to add something additional to themes as they can already be extended. We simply need to allow users to specify a different theme. In this case we may also want to add a ThemeSelectorSPI that would allow some custom logic to select the theme (could be based on headers for instance in the case of a mobile theme). On 16 January 2018 at 14:09, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: We can probably do some builtin support for clients into the themes itself. Doing it properly may take few days. Depends if we want to support that. AFAIR Stian didn't like that, but to me it makes sense that some people want different look&feel based on client. For example template file can be lookup from the directory with the clientId (EG. theme/my-theme/login/customer-portal/login.ftl ). If it doesn't exists, then fallback to the current location without "clientId" directory. Maybe something similar would be needed for the CSS files and other resources. But for some very basic cases, people can probably already handle it by add some "if" into the freemarker template itself and use different CSS styles based on the client or something like this. Marek On 16/01/18 00:09, Bill Burke wrote: I wonder how hard it would be to implement? On Mon, Jan 15, 2018 at 3:22 PM, Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: I think that Freemarker theme (at least login theme) has access to ClientBean through the "client" expression . So it's likely already possible to do some hacking in the template itself and provide different CSS according to the client used. Not very nice, but likely should be somehow possible. Marek On 15/01/18 18:26, Josh Cain wrote: Was originally discussed here: http://lists.jboss.org/pipermail/keycloak-user/2016- <http://lists.jboss.org/pipermail/keycloak-user/2016-> January/004288.html And I asked the same question again here: http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html <http://lists.jboss.org/pipermail/keycloak-user/2016-July/007052.html> But feel free to keep bumping. It's a feature I'd like to see anyway ;-) Josh Cain Senior Software Applications Engineer, RHCE Red Hat North America jcain(a)redhat.com <mailto:jcain@redhat.com> IRC: jcain On 01/15/2018 06:10 AM, eric.kapitza(a)web.de <mailto:eric.kapitza@web.de> wrote: _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user> _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>