[keycloak-dev] 1.2.beta1 planning, need you to defer things

[Vlastimil Elias]

Hi

On 12.3.2015 15:48, Bill Burke wrote:
>
> On 3/12/2015 10:41 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at 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
jboss.org Development Team