[keycloak-dev] POST to /realms/{realm}/account/password results in server 500

[Stian Thorgersen]

We should add proper REST support to account, see https://issues.jboss.org/browse/KEYCLOAK-943

----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, March 4, 2015 7:31:06 PM
> Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results in server 500
> 
> Thanks for the reply Bill. Raised as
> https://issues.jboss.org/browse/KEYCLOAK-1081
> 
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
> Sent: Wednesday, March 04, 2015 12:00 PM
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] POST to /realms/{realm}/account/password results
> in server 500
> 
> The stateChecker exists to protect against CSRF browser attacks.  I think we
> can ignore this check if the request is bearer authenticated.
> Submit a JIRA please?
> 
> On 3/4/2015 11:47 AM, Daniel Baxter wrote:
> > Hi,
> >
> > I am trying to implement a remote user password change  for the logged
> > in user. This is a requirement for the protocol we are required to
> > support which accepts xml formatted commands over a network port, one
> > of which is a password change request. The user is logged in via a
> > Direct Grant from the Remoting application and we have a full
> > KeycloakPrincipal attached to each remote session. When I POST to the
> > form at /realms/{realm}/account/password using a Bearer Auth the
> > password does reset but I get a 500 status back from Keycloak. The
> > issue is that it is trying to rebuild an html response from the
> > 'password.ftl' template and it does not have a value for 'stateChecker'.
> >
> > After reviewing the code on github I found that if you use Bearer
> > Auth,
> > AccountService.init() never initializes a value to stateChecker. So
> > even though I passed one in as a cookie on the POST and inside the
> > form itself it never gets read. The workaround is to use cookies only
> > to handle the authentication mechanism; specifically
> > KEYCLOAK_STATE_CHECKER and KEYCLOAK_IDENTITY and not include Bearer
> > authentication at all. So there is a workaround and it requires the
> > use of cookies only and not Bearer Auth. I know this is not really the
> > intended use of the POST to this form (eg: using it like a REST
> > endpoint), but if anyone else runs into this issue at least they can
> > learn from what I found by searching the mailing list archives.
> >
> > So this leaves me with a couple of questions
> >
> > Why does using Bearer Auth not initialize some sort of value for
> > stateChecker here (ie: Is this a bug)? When you use cookies it appears
> > to even generate a value for stateChecker if none is found in the cookie.
> >
> > What is the purpose of embedding it as a hidden input on the password
> > change form? It appears to never get read when the form is processed
> > anyways.
> >
> > Thanks,
> >
> > Daniel
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>