3:38 p.m.
I'm planning to start to submit some PRs for
https://issues.jboss.org/browse/KEYCLOAK-4853 . If I start to get them to
you in the next few days, what would release would they target. Some of
the items I'm looking to immediately leverage are:
- Create User
- Create Group
- Create IDP
These are the important ones since fetching the data a second go around
requires that unique ID in the URL.
John
6:51 a.m.
The unique ID is being returned as part of the Location header. This is a
standard way of doing things. I don't like your proposal of returning an ID
header as that's something custom that at least I've not seen done
elsewhere.
I appreciate the fact that the Location header has to be parsed, but adding
a new custom header isn't the solution IMO.
We would not consider this for 3.x so it wouldn't be merged until the new
year at the earliest. We'd also need an agreed pattern that should be
discussed on the mailing list prior to sending a PR. It would have to be
complete (all endpoints updated) and come with tests.
On 14 December 2017 at 15:38, John D. Ament <john.d.ament(a)gmail.com> wrote:
I'm planning to start to submit some PRs for
https://issues.jboss.org/browse/KEYCLOAK-4853 . If I start to get them to
you in the next few days, what would release would they target. Some of
the items I'm looking to immediately leverage are:
- Create User
- Create Group
- Create IDP
These are the important ones since fetching the data a second go around
requires that unique ID in the URL.
John
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:57 p.m.
Stian,
On Mon, Dec 18, 2017 at 12:51 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
The unique ID is being returned as part of the Location header. This
is a
standard way of doing things. I don't like your proposal of returning an ID
header as that's something custom that at least I've not seen done
elsewhere.
I appreciate the fact that the Location header has to be parsed, but
adding a new custom header isn't the solution IMO.
Agreed. I wanted to better understand where we're struggling. Looking at
the code, would it make sense for Keycloak's Admin client to provide a
utility that can parse the header to retrieve the ID portion of the URL, so
that consumers don't need to parse it themselves?
We would not consider this for 3.x so it wouldn't be merged until the new
year at the earliest. We'd also need an agreed pattern that should be
discussed on the mailing list prior to sending a PR. It would have to be
complete (all endpoints updated) and come with tests.
On 14 December 2017 at 15:38, John D. Ament <john.d.ament(a)gmail.com>
wrote:
> I'm planning to start to submit some PRs for
> https://issues.jboss.org/browse/KEYCLOAK-4853 . If I start to get them
> to
> you in the next few days, what would release would they target. Some of
> the items I'm looking to immediately leverage are:
>
> - Create User
> - Create Group
> - Create IDP
>
> These are the important ones since fetching the data a second go around
> requires that unique ID in the URL.
>
> John
>
_______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2:13 p.m.
On 18 December 2017 at 13:57, John D. Ament <john.d.ament(a)gmail.com> wrote:
Stian,
On Mon, Dec 18, 2017 at 12:51 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> The unique ID is being returned as part of the Location header. This is a
> standard way of doing things. I don't like your proposal of returning an ID
> header as that's something custom that at least I've not seen done
> elsewhere.
>
> I appreciate the fact that the Location header has to be parsed, but
> adding a new custom header isn't the solution IMO.
>
Agreed. I wanted to better understand where we're struggling. Looking at
the code, would it make sense for Keycloak's Admin client to provide a
utility that can parse the header to retrieve the ID portion of the URL, so
that consumers don't need to parse it themselves?
That would probably be the simplest option. We already to this in the
testsuite with:
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-ar...
Could you extract the getCreatedId method to a new Util class within
admin-client
>
> We would not consider this for 3.x so it wouldn't be merged until the new
> year at the earliest. We'd also need an agreed pattern that should be
> discussed on the mailing list prior to sending a PR. It would have to be
> complete (all endpoints updated) and come with tests.
>
> On 14 December 2017 at 15:38, John D. Ament <john.d.ament(a)gmail.com>
> wrote:
>
>> I'm planning to start to submit some PRs for
>> https://issues.jboss.org/browse/KEYCLOAK-4853 . If I start to get them
>> to
>> you in the next few days, what would release would they target. Some of
>> the items I'm looking to immediately leverage are:
>>
>> - Create User
>> - Create Group
>> - Create IDP
>>
>> These are the important ones since fetching the data a second go around
>> requires that unique ID in the URL.
>>
>> John
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
2314
days inactive
2318
days old
3 comments
2 participants
participants (2)
-
John D. Ament -
Stian Thorgersen