Javascript and css3 can already be done as those won't require any updates to
Keycloak. I'm not sure if that will cover all cases though. So me may need to expose
at least user-agent header, we could also make the client_id available to the themes.
----- Original Message -----
From: "Marek Posolda" <mposolda(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>, "Bill Burke"
<bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Monday, 22 September, 2014 9:06:39 AM
Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
I wonder there might be some more browser javascript properties, which
might help to detect client type. For example screen.width (with low
values, there is quite big chance that you are using mobile device).
Also it might be useful to detect if device support touch screen or not
(not sure if there is some reliable way though). If we go this way, it
might be also helpful to cache the detected client type into cookie, so
detection doesn't need to be done in each request.
Marek
On 19.9.2014 16:27, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 19 September, 2014 3:19:13 PM
>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>
>> Browsers set the User-Agent header. Wouldn't it be better to pick the
>> theme based on the user-agent header? I don't remember if browsers also
>> automatically push locale info.
> User-Agent header is useful, but I think we may something in addition, for
> example when form is displayed embedded instead of full page redirect. Not
> 100% sure user-agent is always reliable either.
>
> Browsers set's Accept-Language header, but apparently it's not always
> reliable so it's only recommended to use it as a starting point. I've got
> a proposal for internationalization support here:
>
https://issues.jboss.org/browse/KEYCLOAK-301
>
>> On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
>>> Another thing we should consider is embedding of the login form. Instead
>>> of
>>> doing a full-page redirect we could allow embedding using a modal and/or
>>> iframe. In that situation you'd also want it to look slightly different
>>> than the full-page version.
>>>
>>> ----- Original Message -----
>>>> From: "Lukáš Fryč" <lukas(a)fryc.eu>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>,
>>>> keycloak-dev(a)lists.jboss.org
>>>> Sent: Friday, 19 September, 2014 2:49:43 PM
>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
>>>> theme
>>>>
>>>> I completely agree that the SSO should have same look for all
>>>> applications
>>>> using one realm.
>>>>
>>>>
>>>> Yes, a customization can be partially achieved just with CSS tweaks,
but
>>>> it
>>>> doesn't have to meet all requirements and further per-platform
tweaks
>>>> may
>>>> be necessary.
>>>>
>>>> In the Ionic demo above I was to meet 70% cases by using built-in CSS
>>>> classes. The rest had to be hard-coded. We can either extend CSS
classes
>>>> coverage or allow higher customization with e.g. theming per variants.
>>>>
>>>> This feature would make "theming per-platform" easier, I could
achieve
>>>> that
>>>> with pure CSS/HTML tweaks and media-queries anyway.
>>>>
>>>> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen
<stian(a)redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Lukáš Fryč" <lukas.fryc(a)gmail.com>
>>>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>>>> Cc: "AeroGear Developer Mailing List"
<aerogear-dev(a)lists.jboss.org>,
>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Friday, 19 September, 2014 1:30:21 PM
>>>>>> Subject: Re: [aerogear-dev] [keycloak-dev] Keycloak Ionic /
Cordova
>>>>> theme
>>>>>> That would be awesome,
>>>>>>
>>>>>> do I read correctly that it is not possible at the moment?
Should I
>>>>> create a
>>>>>> feature request?
>>>>> Currently we can only configure the theme on a per-realm basis.
With
>>>>> the
>>>>> exception of css media-types there's not currently any way to
modify
>>>>> the
>>>>> l&f based on client (or client type).
>>>>>
>>>>> An alternative, which may make more sense, is to add multiple
variants
>>>>> of
>>>>> a theme. So for example you could have a theme that has web,
android,
>>>>> ios,
>>>>> etc variants. Then you have some way of specifying for the client
what
>>>>> variant it is. The reason this may make more sense is so that the
SSO
>>>>> login
>>>>> screen looks the same whichever application you come from.
>>>>>
>>>>> For example Acme Inc may have two applications (both with web, ios
and
>>>>> android variants):
>>>>>
>>>>> * calendar
>>>>> * mail
>>>>>
>>>>> You want the login screen to be adapted to the variant of the apps.
So
>>>>> the
>>>>> login screens can look different if you use a browser or if you use
a
>>>>> mobile. What you don't want is the login screens to look
different for
>>>>> the
>>>>> calendar and mail applications, as it's SSO you're not
logging in to an
>>>>> app, you're looging in to a group of apps.
>>>>>
>>>>> Can we reliably detect what variant it is? Or does this have to be
>>>>> configured in the admin console on a per-client basis?
>>>>>
>>>>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen <
stian(a)redhat.com >
>>>>> wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Lukáš Fryč" < lukas(a)fryc.eu >
>>>>>>> To: "Stian Thorgersen" < stian(a)redhat.com >
>>>>>>> Cc: "AeroGear Developer Mailing List" <
aerogear-dev(a)lists.jboss.org
>>>>>> ,
>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
>>>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic /
Cordova
>>>>> theme
>>>>>>> IMHO the SSO endpoint could either detect an incoming client
(that
>>>>> would be
>>>>>>> rather complex)
>>>>>>>
>>>>>>> or simply allow user client preference. Can we allow more
than one
>>>>> theme
>>>>>>> per realm and let the client app choohse?
>>>>>> Not sure what you mean, we always know which client is
requesting the
>>>>> login
>>>>>> (it's the client_id query param). The client should only be
used for
>>>>>> one
>>>>>> variant of an application as well (so for an app that has a
web,
>>>>>> android
>>>>> and
>>>>>> ios variants, there should be 3 clients configured in KC). So
there's
>>>>>> no
>>>>>> problem providing an option to override the theme on a
per-client
>>>>>> basis.
>>>>>>
>>>>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <
stian(a)redhat.com
>>>>>>> >
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This raises the question. Should we allow overriding the
theme on an
>>>>>>>> per-application basis?
>>>>>>>>
>>>>>>>> It would allow a better integration with the app, but on
the other
>>>>> side
>>>>>>>> does it even make sense to login to a SSO realm that
way?
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Erik Jan de Wit" <
edewit(a)redhat.com >
>>>>>>>>> To: "AeroGear Developer Mailing List"
<
>>>>> aerogear-dev(a)lists.jboss.org >
>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
>>>>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova
theme
>>>>>>>>>
>>>>>>>>> Looks very nice, will this integrate well with the
work that
>>>>> Summers
>>>>>>>>> did?
>>>>>>>>>
>>>>>>>>> On 18 Sep,2014, at 20:19 , Lukáš Fryč <
lukas.fryc(a)gmail.com >
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yeah and off course, the source is here:
>>>>>>>>>
>>>>>>>>>
https://github.com/lfryc/keycloak/tree/ionic-styling
>>>>>>>>>
>>>>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Lukáš Fryč <
lukas.fryc(a)gmail.com
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hey guys,
>>>>>>>>>
>>>>>>>>> I've started some work on a theme for Keycloak
that would include
>>>>> Ionic
>>>>>>>>> Framework styling.
>>>>>>>>>
>>>>>>>>> This makes sure that Ionic/Cordova demos that
includes Keycloak has
>>>>>>>> smooth
>>>>>>>>> transition between application and login process /
registration.
>>>>>>>>>
>>>>>>>>> See attached screenshots.
>>>>>>>>>
>>>>>>>>> It's still in early prototypal stage, so just
just login,
>>>>> registration
>>>>>>>> and
>>>>>>>>> social (only google) fully works so far, but others
can be simply
>>>>>>>> expanded.
>>>>>>>>> Feel free to use it in demos or so... ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> ~ Lukas
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>>
http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev