My branch has now been updated to also include ability to override
template on a client or client template.
It's here:
https://github.com/stianst/keycloak/tree/KEYCLOAK-6289 if
anyone wants to take a look
On 17 January 2018 at 12:38, Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
[Added the list back]
To reply to everyone just do "reply all" and it should include the
list.
On 17 January 2018 at 10:29, <eric.kapitza(a)web.de
<mailto:eric.kapitza@web.de>> wrote:
Hello Stian, Hello Marek,
I really love that you want to developt this feature! :)
I think it's good if you can set the theme per client, with a
fallback to the default theme. This is probably what most
people need when they look for this feature.
Btw how do I correctly reply to somebody like you did, so
everyone will get the new message? Must I just send a new mail
to the email list with the same title?
One other question, maybe you know it, do you think it is
right now technically possible to use keycloak login page
within an IFrame in our application with JS-Adapter?
Eric
*Gesendet:* Mittwoch, 17. Januar 2018 um 09:38 Uhr
*Von:* "Stian Thorgersen" <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>
*An:* "Marek Posolda" <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>>
*Cc:* keycloak-user <keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>>
*Betreff:* Re: [keycloak-user] Different theme for each client
On 17 January 2018 at 09:35, Marek Posolda
<mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote:
> On 17/01/18 09:03, Stian Thorgersen wrote:
>
> 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.
>
> I think that yes. It can be cumbersome, but this applies for
many
> client-specific settings. For example you may have some custom
> protocolMapper, which you want to use for more clients and
then you also
> need to edit protocolMappers in all clients to add this custom
> protocolMapper.
>
> We can also support theme per clientTemplate, so if client
doesn't have
> theme set, it can try the theme from clientTemplate and
fallback to realm
> and finally to default if nothing is set.
>
OK. I guess implementation should be pretty straightforward as
both clients
and client templates have attributes.
>
>
> Marek
>
>
> [1]
https://github.com/stianst/keycloak/tree/KEYCLOAK-6289
<
https://github.com/stianst/keycloak/tree/KEYCLOAK-6289>
> [2]
https://github.com/stianst/keycloak/blob/KEYCLOAK-6289/services/src/
<
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(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/007
<
http://lists.jboss.org/pipermail/keycloak-user/2016-July/007>
>>>>>>>>> 052.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>
>>>
>>
>>
>>
>
>
_______________________________________________
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>