Yes it changed in 1.3 to ID. We're making the same API call as the admin
console does only we're doing it right after the user is created if they
don't meet certain criteria in client. These are social logins.
We're using MySQL but that shouldn't matter. Perhaps something Keycloack
server side is holding reference to the user. I'll try to provide more
information in a few days but wasn't sure if anyone saw this behavior
before.
Thanks,
Scott
On Tue, Jun 30, 2015 at 8:27 AM Marek Posolda <mposolda(a)redhat.com> wrote:
Hi Scott,
I've just tried this with latest Keycloak master and deleting the user
from admin console works fine (I used default JPA with HSQLDB database).
Can you also check with admin console? If deleting through admin console
works fine, then there is likely something bad in the way you're
invoking the REST endpoint.
BTV. in latest master you're supposed to invoke the REST endpoint with
user id instead of "username" as last parameter. But I am not sure if it
was really username in 1.2.0 and it changed to ID in latest version...
Marek
On 30.6.2015 04:57, Scott Rossillo wrote:
> In 1.2.0, an HTTP delete on
“/auth/admin/realms/{realm}/users/{username}” returns a 200 OK, but the
user still exists. A second call usually succeeds at actually deleting the
user. Seems like a bug.
>
> Thoughts?
>
> ~ Scott
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev