<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 26/09/16 16:41, Dmitry Telegin
wrote:<br>
</div>
<blockquote cite="mid:1474900897.7390.25.camel@cargosoft.ru"
type="cite">
<div>Hi,</div>
<div><br>
</div>
<div>The org.keycloak.events.* subsystem could potentially be of
great use for KeyCloak extensions (providers), especially for
combinations of JpaEntityProvider+RealmResourceProvider. Imagine
we've implemented a custom entity + REST resource, and we want
to log create/update/delete events for our entity, and then
analyze log records in the event viewer inside admin console.</div>
<div><br>
</div>
<div>Unfortunately, the event subsystem in its current state is
not very useful for the above. This is due to resource types
hardcoded into org.keycloak.events.admin.ResourceType enum. When
logging events for a custom entity, the only option is to leave
resource type empty:</div>
<div><br>
</div>
<pre> adminEvent</pre>
<pre> .operation(OperationType.CREATE)</pre>
<pre> .resourcePath(uriInfo, myEntity.getId())</pre>
<pre> .representation(rep)</pre>
<pre> .success();</pre>
<pre>
</pre>
<div>This will obviously create a log record without a "Resource
Type" value, which is definitely not of great use.</div>
<div><br>
</div>
<div>It would be nice to have extensible ResourceType. One of the
approaches to the extensible enum problem is described here: <a
moz-do-not-send="true"
href="https://blogs.oracle.com/darcy/entry/enums_and_mixins">https://blogs.oracle.com/darcy/entry/enums_and_mixins</a></div>
<div>I think this could be applied here with minimal
modifications. ResourceType would become an interface, and there
would be introduced something like StandardResourceType enum,
which would implement built-in resource types as enum keys, and
store custom types in a static map-backed registry. A public
static method would be introduced so that extension authors
could register their own resource types. In the future, when (I
hope) registering providers will be done with annotations, this
could be even more simplified and made purely declarative.</div>
</blockquote>
+1<br>
<br>
Maybe even easier if ResourceType will be just a wrapper around
String, so if you do:<br>
adminEvent.<br>
.operation(OperationType.CREATE)<br>
.resourceType(ResourceType.from("MY_FOO_RESOURCE"))<br>
...<br>
<br>
it will just work. No need to register anything. Should be backwards
compatible too. Not sure which approach is better...<br>
<blockquote cite="mid:1474900897.7390.25.camel@cargosoft.ru"
type="cite">
<div><br>
</div>
<div>The same approach could be applied to extending login events
(potentially useful for custom authenticators etc.) What do you
think? If everybody is OK with it, I can go on with JIRA and a
PR.</div>
</blockquote>
The login events already has "details", which allow you to add here
any custom fields you want? Isn't that sufficient?<br>
<br>
Marek<br>
<blockquote cite="mid:1474900897.7390.25.camel@cargosoft.ru"
type="cite">
<div><br>
</div>
<div>Cheers,</div>
<div>Dmitry</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
keycloak-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<p><br>
</p>
</body>
</html>