[keycloak-dev] Release status

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 21 July, 2015 5:15:48 PM
> Subject: Re: [keycloak-dev] Release status
> 
> 
> 
> On 7/21/2015 4:54 AM, Stian Thorgersen wrote:
> > I'd like all changes in and issues fixed by the end of the week for 1.4
> > release. There's still quite a few issues remaining.
> >
> >
> > Auth/required actions:
> > ----------
> > There's quite a few issues outstanding in JIRA related to the new
> > authentication SPIs:
> >
> > KEYCLOAK-1457 Auth flow for non-browser auth
> > KEYCLOAK-1552 NPE if brute force detection enabled
> > KEYCLOAK-1508 Re-Login fails after session timeout
> > KEYCLOAK-1489 auth timeouts should restart flow
> > KEYCLOAK-1481 reimplement AuthenticationManagerTest
> > KEYCLOAK-1466 Find better way to propagate BruteForceProtector
> > KEYCLOAK-1465 Cleanup obsolete auth code
> > KEYCLOAK-1463 Need better UI for Terms and Conditions
> > KEYCLOAK-1457 Auth flow for non-browser auth
> > KEYCLOAK-1455 remove user.isTotp() usage
> > KEYCLOAK-1450 Re-enable Brute Force Protection
> >
> 
> I'm working on 1457 right now which is a blocker for 1465.
> 
> > Also, what's the status with regards to:
> >
> > * Migration
> 
> Implemented.  Not really tested beyond what we already have for test
> scripts.
> 
> > * Is brute force enabled?
> 
> Need to work on this this week.
> 
> > * Is the improvements with regards to login time outs added?
> 
> Still some work here.
> 
> > * Do we need to polish the UI with regards to auth work?
> >
> 
> Yes, we need some polish.  I'm horrible at creating nice UIs unless
> there is some template to work from.  I don't have one to work from for
> the auth work.

I can take a stab at cleaning it up a little bit - then we can have the UXP guys review it later

> 
> > Other things:
> > -------------
> > * KEYCLOAK-1539	Accessing secured resource should not return 200 OK when
> > not authenticated - adapters redirect to login page even for json/xml
> > requests. That doesn't make any sense. We should only redirect to login
> > page if Accept header is */*, text/* or text/html.
> 
> We're not changing the adapters to change their response based on Accept
> header.  That is a horrible hack solution.  See my recent comment on
> this issue in jira.

I don't understand why that's a hack solution? Returning a redirect to a html page for something requesting a json document just isn't right.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>