[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> 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>
*An:* "Marek Posolda" <mposolda(a)redhat.com>
*Cc:* keycloak-user <keycloak-user(a)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> 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
> [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(a)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(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/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 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
>>>
>>
>>
>>
>
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user