[keycloak-user] Different theme for each client

Stian Thorgersen sthorger at redhat.com
Wed Jan 17 06:38:41 EST 2018 

[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 at 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 at redhat.com>
> *An:* "Marek Posolda" <mposolda at redhat.com>
> *Cc:* keycloak-user <keycloak-user at lists.jboss.org>
> *Betreff:* Re: [keycloak-user] Different theme for each client
> On 17 January 2018 at 09:35, Marek Posolda <mposolda at 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 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/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 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
> >>>
> >>
> >>
> >>
> >
> >
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

More information about the keycloak-user mailing list