[keycloak-user] Different theme for each client

[Stian Thorgersen]

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/java/org/keycloak/theme/DefaultThemeSelectorProvider.java#L17

On 17 January 2018 at 08:54, Marek Posolda <mposolda at 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
>>
>> On 16 January 2018 at 17:06, Josh Cain <jcain at 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 at 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 at 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 at 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-
>>>>>>>>
>>>>>>> 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 at redhat.com IRC: jcain
>>>>>>>>
>>>>>>>> On 01/15/2018 06:10 AM, eric.kapitza at web.de wrote:
>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-user mailing list
>>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>