<div dir="ltr">Answers inline<br><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 19:52 GMT+01:00 Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">We've decided to leave the admin endpoints as is for 1.x series. In 2.x series we'll introduce a version 2 of the API which won't be backwards compatible. This will give us greater flexibility in improving the API, but still support the older API for some time.<br><div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>Sounds reasonable - will keep that in mind! </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 19 January 2016 at 12:20, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>I just wanted to ensure backwards compatibility - an additional parameter would break (java) API </div><div>consumers who are currently using the keycloak-admin-client, since they are potentially using the </div><div>variant without the parameter. </div><div>This would of course be no problem for REST API consumers.</div><div><br></div><div>What I see as a problem though is the behaviour change of the search behaviour by default ... </div><div>(knowing the current API) I'd rather expect that the search would perform the same as before </div><div>with fuzzy matching /by default/ and support for exact match if explicitly stated.</div><div><br></div><div>However having a search operation that performs an exact search by </div><div>default "feels" more natural to me - so I'm fine with your suggestion as a quick solution :) </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Regarding urls:</div><div>I'd rather prefer to have some dedicated search sub-resources per entity - but that is a more general topic...</div><div>With this approach one would be more flexible with respect to supported searches</div><div>that could behave completly different.</div><div><br></div><div>Entity lookups by id</div><div> /entity/{id}</div><div><br></div><div>Dedicated lookup sub-resource for other attribute lookups: (here I'd expect exactly 0 or 1 results)</div><div> /entity/lookup/byName?name=someName</div><div> /entity/lookup/byEmail?email=someEmail</div><div><br></div><div>Dedicated search sub-resources: (here I'd expect 0 or n results)</div><div><br></div><div> /entity/search/byName?name=someName</div><div> /entity/search/byNameMatching?pattern=someName</div><div> /entity/search/byAttributes?firstname=firstname&lastname=lastname</div></div></blockquote><div><br></div></span><div>-1 A single resource with different query params is much cleaner IMO</div><span class=""><div> </div></span></div></div></div></blockquote><div>Yes and no, it may look cleaner to some degree in the beginning but once more sophisticated </div><div>user searches / lookups become necessary it can turn into a mess because one has to deal</div><div>with a bunch of different parameters and handle the resulting parameter combinations in a proper way. </div><div>Having dedicated search endpoints makes it easier to provide narrowly focused search APIs IMHO.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>In addition to that one could also allow @POST requests to these (sub-)resources</div><div>where the actual parameters are extracted from form-parameters in order</div><div>to avoid leaking user information like username, email, etc. in access logs.</div><div>I think this would be relevant for an application that deals with security sensitive information</div><div>like keycloak does.</div></div></blockquote><div><br></div></span><div>Agree with the security sensitivity, but it sounds very non-rest</div><div><div class="h5"><div> </div></div></div></div></div></div></blockquote><div>Yes indeed, that's one occasion where one has to deviate from traditional rest teachings for the sake of security ;-)</div><div>Although using POST requests don't make the whole app more secure but helps, as said to not leave unnecessary</div><div>traces in proxy / access logs etc.</div><div><a href="http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other">http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div>Thomas</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 11:49 GMT+01:00 Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">-1 To additional search method. URL should be '.../users'.<div><br></div><div>Simplest is just to change what we have now to not included wildcards. Then add an extra query param "fuzzy". If fuzzy=true then we'd add %. Default should be false. Alternatives are:</div><div><br></div><div>* Let users add % themselves</div><div>* Add separate query params for fuzzy</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 19 January 2016 at 10:27, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I created: <a href="https://issues.jboss.org/browse/KEYCLOAK-2343" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-2343</a> to track this.</div><div><br></div><div>Cheers,</div><div>Thomas</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 10:15 GMT+01:00 Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>Okay, how about offering a new search method that accepts s UserSearch DTO that would hold the attributes to search by </div><div>as well as a "match mode". Could also be used to specify pagination.</div><div><br></div><div>This could also be send via a @POST in order to avoid retaining userdata like usernames, email addresses etc. in </div><div>access logs...</div><div><br></div><div>Alternatively you could introduce a searchExact(..) method with the same parameterization as the existing search method.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 10:07 GMT+01:00 Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">It was by design, but it wasn't a good design. Would be better to make it match exact, but allow including a wildcard to make it fuzzy.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 19 January 2016 at 09:58, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><div>Hi,</div><div><br></div><div>I was looking for a way to query users based on their exact username but it turned out, that</div><div> org.keycloak.admin.client.resource.UsersResource.search(String, String, String, String, Integer, Integer)</div><div><br></div><div> @GET</div><div> @Produces(MediaType.APPLICATION_JSON)</div><div> List<UserRepresentation> search(@QueryParam("username") String username,</div><div> @QueryParam("firstName") String firstName,</div><div> @QueryParam("lastName") String lastName,</div><div> @QueryParam("email") String email,</div><div> @QueryParam("first") Integer firstResult,</div><div> @QueryParam("max") Integer maxResults);</div><div><br></div><div> ...</div><div> usersResource.search("exactusername",null,null, null, null, email, 0, 10)</div><div><br></div><div>generates a like %..% query in JpaUserProvider.searchForUserByAttributes(...).</div><div><br></div><div>Since usernames are unique per realm I think it would make sense to be able to perform a</div><div>query for the exact username (or perhaps the combination of other attributes as well).</div><div><br></div><div>Was this omitted by design, or may I create a JIRA for this?</div><div><br></div><div>Cheers,</div><div>Thomas</div></div>
<br></div></div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>