<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 January 2016 at 20:48, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Answers inline<br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">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></span><div>Sounds reasonable - will keep that in mind! </div><span class=""><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>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><div> </div></span></div></div></div></blockquote></span><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></div></blockquote><div><br></div><div>It always depends. I can't see us providing so many different search endpoints that having multiple different endpoints will be cleaner. Having one endpoint with multiple params also provides more flexibility. For even more flexibility you can use something along what Mongo does to include a complex json object for the search params.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><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><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><div> </div></div></div></div></div></div></blockquote></span><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" target="_blank">http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other</a></div></div></div></div></blockquote><div><br></div><div>Assuming HTTPS is used then the only place that query params could be leaked is in the web server log, so wouldn't it be more sensible to make sure they are not included in the server logs?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><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><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></div></div><br></div></div>
</blockquote></div><br></div></div>