9:45 a.m.
Hi,
currently it is hard to figure out what actually happend when processing
events, since there
is no explicit information about the actual underlying resource in an
event. Currently one has to
parse the resourcePath of an AdminEvent to deduce the involved resource.
E.g. Creating a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
Assigning a client role to a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
Removing a client role from a user yields:
AdminEvent#getOperationType(): DELETE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
It would be helpful if one had more information about the actual use case.
How about introducing an AdminEvent#getResourceType() method that returns
an enum value for the
resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
This would make it easier detect what actually happend without having to
parse the resourcePath.
What do you think?
Cheers,
Thomas
9:55 a.m.
Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
don't have to have the logic spread around.
On 15 January 2016 at 09:45, Thomas Darimont <thomas.darimont(a)googlemail.com
wrote:
Hi,
currently it is hard to figure out what actually happend when processing
events, since there
is no explicit information about the actual underlying resource in an
event. Currently one has to
parse the resourcePath of an AdminEvent to deduce the involved resource.
E.g. Creating a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
Assigning a client role to a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
Removing a client role from a user yields:
AdminEvent#getOperationType(): DELETE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
It would be helpful if one had more information about the actual use case.
How about introducing an AdminEvent#getResourceType() method that returns
an enum value for the
resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
This would make it easier detect what actually happend without having to
parse the resourcePath.
What do you think?
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:06 a.m.
Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
Cheers,
Thomas
2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger(a)redhat.com>:
Sounds good to me. The AdminEventBuilder.resourcePath could set it so
we
don't have to have the logic spread around.
On 15 January 2016 at 09:45, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
> Hi,
>
> currently it is hard to figure out what actually happend when processing
> events, since there
> is no explicit information about the actual underlying resource in an
> event. Currently one has to
> parse the resourcePath of an AdminEvent to deduce the involved resource.
>
> E.g. Creating a user yields:
>
> AdminEvent#getOperationType(): CREATE
> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>
> Assigning a client role to a user yields:
>
> AdminEvent#getOperationType(): CREATE
> AdminEvent#getResourcePath():
>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
> Removing a client role from a user yields:
> AdminEvent#getOperationType(): DELETE
> AdminEvent#getResourcePath():
>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
> It would be helpful if one had more information about the actual use case.
>
> How about introducing an AdminEvent#getResourceType() method that returns
> an enum value for the
> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>
> This would make it easier detect what actually happend without having to
> parse the resourcePath.
>
> What do you think?
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
10:47 a.m.
For the record we can't prioritize it at the moment
On 15 January 2016 at 10:06, Thomas Darimont <thomas.darimont(a)googlemail.com
wrote:
> Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
>
> Cheers,
> Thomas
>
> 2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger(a)redhat.com>:
>
>> Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
>> don't have to have the logic spread around.
>>
>> On 15 January 2016 at 09:45, Thomas Darimont <
>> thomas.darimont(a)googlemail.com wrote:
>>
>>> Hi,
>>>
>>> currently it is hard to figure out what actually happend when processing
>>> events, since there
>>> is no explicit information about the actual underlying resource in an
>>> event. Currently one has to
>>> parse the resourcePath of an AdminEvent to deduce the involved resource.
>>>
>>> E.g. Creating a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>>>
>>> Assigning a client role to a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath():
>>>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> Removing a client role from a user yields:
>>> AdminEvent#getOperationType(): DELETE
>>> AdminEvent#getResourcePath():
>>>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> It would be helpful if one had more information about the actual use
>>> case.
>>>
>>> How about introducing an AdminEvent#getResourceType() method that
>>> returns an enum value for the
>>> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
>>> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>>>
>>> This would make it easier detect what actually happend without having to
>>> parse the resourcePath.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
1:47 p.m.
Ok, I can give it a spin this evening
Cheers,
Thomas
2016-01-15 10:47 GMT+01:00 Stian Thorgersen <sthorger(a)redhat.com>:
For the record we can't prioritize it at the moment
On 15 January 2016 at 10:06, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
> Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
>
> Cheers,
> Thomas
>
> 2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger(a)redhat.com>:
>
>> Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
>> don't have to have the logic spread around.
>>
>> On 15 January 2016 at 09:45, Thomas Darimont <
>> thomas.darimont(a)googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> currently it is hard to figure out what actually happend when
>>> processing events, since there
>>> is no explicit information about the actual underlying resource in an
>>> event. Currently one has to
>>> parse the resourcePath of an AdminEvent to deduce the involved resource.
>>>
>>> E.g. Creating a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>>>
>>> Assigning a client role to a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath():
>>>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> Removing a client role from a user yields:
>>> AdminEvent#getOperationType(): DELETE
>>> AdminEvent#getResourcePath():
>>>
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> It would be helpful if one had more information about the actual use
>>> case.
>>>
>>> How about introducing an AdminEvent#getResourceType() method that
>>> returns an enum value for the
>>> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
>>> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>>>
>>> This would make it easier detect what actually happend without having
>>> to parse the resourcePath.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
3:02 p.m.
You've done some good work Thomas. Thanks for your contributions!
On 1/15/2016 7:47 AM, Thomas Darimont wrote:
Ok, I can give it a spin this evening
Cheers,
Thomas
2016-01-15 10:47 GMT+01:00 Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>:
For the record we can't prioritize it at the moment
On 15 January 2016 at 10:06, Thomas Darimont
<thomas.darimont(a)googlemail.com
<mailto:thomas.darimont@googlemail.com>> wrote:
Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
Cheers,
Thomas
2016-01-15 9:55 GMT+01:00 Stian Thorgersen
<sthorger(a)redhat.com <mailto:sthorger@redhat.com>>:
Sounds good to me. The AdminEventBuilder.resourcePath
could set it so we don't have to have the logic spread around.
On 15 January 2016 at 09:45, Thomas Darimont
<thomas.darimont(a)googlemail.com
<mailto:thomas.darimont@googlemail.com>> wrote:
Hi,
currently it is hard to figure out what actually
happend when processing events, since there
is no explicit information about the actual underlying
resource in an event. Currently one has to
parse the resourcePath of an AdminEvent to deduce the
involved resource.
E.g. Creating a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472
Assigning a client role to a user yields:
AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
Removing a client role from a user yields:
AdminEvent#getOperationType(): DELETE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
It would be helpful if one had more information about
the actual use case.
How about introducing an AdminEvent#getResourceType()
method that returns an enum value for the
resource in question, e.g. USER, ROLE, CLIENT, REALM,
GROUP, ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT,
GROUP_ASSIGNMENT, etc.
This would make it easier detect what actually happend
without having to parse the resourcePath.
What do you think?
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3031
days inactive
3031
days old
5 comments
3 participants
participants (3)
-
Bill Burke -
Stian Thorgersen -
Thomas Darimont