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]
+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(a)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 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>
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>
>>>>>
>>>> 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
>