On 3/12/2015 10:41 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, 12 March, 2015 1:57:21 PM
>> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things
>>
>>
>>
>> On 3/12/2015 1:40 AM, Stian Thorgersen wrote:
>> ...
>>>> I'm going to try and close existing bugs and implement features
needed
>>>> for
jboss.org guys over the next 2 weeks as well as test out master to
>>>> make sure things still work.
>>> With regards to
jboss.org guys we shouldn't just add features because
they
>>> request it. Take for example KEYCLOAK-1045, which was easily solved with
>>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible
>>> idea.
>>>
>> I don't want to just add features either, but some of their things are
>> valid...i.e. finding out if a user is logged and who they are without
>> doing all the token stuff.
> That's exactly one of the things that are not necessary, I've added a POC
that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and
http://stianst.github.io/jbossorg/index.html.
>
I'll take a look, but IIRC there was a different issue described (not
1045), where a static home page shouldn't have to perform a full login
and obtain a token just to know whether or not a user is logged in and
who they are.
I appreciate our features to be pushed, some working/semistable version
in two or three weeks should be cool for us to be able develop
other/client parts of our solution.
Then we need some production ready version available in the middle of
May at worse.
We can always discuss issues I created in JIRA, if we find some other
solution for our needs then it is OK. Also features marked by
jbossorg_req_opt label (like KEYCLOAK-1051) are not mandatory for us
now, we can probably live without them. But we have to resolve issues
marked by jbossorg_req label somehow as they block us.
Like for KEYCLOAK-1045 we found some solution by improving keycloak.js
for now. But there is room for performance improvements still (I think
you call it "implicit flow" or so in the comments). As real users of
this feature will be some other developers of the final web then they
will maybe push to get these performance improvements implemented later.
I also don't think KEYCLOAK-1051 is so horible idea, I just added
comment to it with my more detailed explanation why ;-)
Thanks guys for the great cooperation which allow us to use KC for our
project, and will help to improve KC in general for other users I believe.
Vl.
--
Vlastimil Elias
Principal Software Engineer