<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 24 June 2016 at 06:34, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.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"><span class="">On 23/06/16 16:31, Bill Burke 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">
First on pagination. I was thinking about this a bit. Do we really think that admins are going to paginate through 1000s of users? Or will it be more like a couple of hundred at most? Right now I've implemented something that is pretty inefficient to keep it backward compatible right now. Basically I iterate all providers from the beginning until the page desired is identified and filled up. Minimally it is a stop gap until I get everything working.<br>
<br>
The API will need to change if we want pagination to work efficiently. Invokers on the API will need to keep an index as we need to know the last provider queried and what was the index for the last entry read. As a result, the REST API would have to change too.<br>
</blockquote></span>
+1 to change the REST API. The admin console already works in a way that there are arrows for the "next" page and "previous" page right? So if we don't have support for "Go directly for users from 1500 to 1600" it won't be a big headache though...<br></blockquote><div><br></div><div>Actually our tables don't follow PatternFly and we need to update them to make it consistent. Take a look at:</div><div><br></div><div><a href="https://www.patternfly.org/pattern-library/widgets/#data-tables">https://www.patternfly.org/pattern-library/widgets/#data-tables</a><br></div><div><br></div><div>It displays total number of items, has previous/next, jump to start/end as well as ability to enter a specific page.</div><div><br></div><div>We could either support pagination properly or we have a maximum items that are fetched. If the latter we'd display a message retrieving N users out of X users or something to indicate that all users are not loaded. However, that's just a poor attempt at pagination isn't it?</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">
<br>
It will be also good for LDAP as some LDAP servers have support for pagination extension. This is based on the functionality, that you can send pagination query to return first 10 users and LDAP will return you a "cookie" for going to next page. So just browsing between "next" page and "previous" page is easily possible. The most important LDAP vendors like MSAD and RHDS have the support for this.</blockquote><div><br></div><div>IMO we should support pagination when possible, but a provider should have the option to not support pagination.</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"><span class=""><br>
<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">
<br>
On 6/23/16 8:53 AM, Stian Thorgersen 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">
Some comments on<br>
<a href="https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI" rel="noreferrer" target="_blank">https://github.com/keycloak/keycloak/wiki/2.0-User-Federation-Storage-SPI</a>: <br>
<br>
* Different cache policies per provider may be difficult. Wouldn't that<br>
require having a Infinispan cache per provider? That wouldn't be very<br>
manageable.<br>
</blockquote>
<br>
I think there is some flexibility here in the Infinispan API. I know the old api at least allowed you to define zones in the cache.<br>
<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">
* My vote goes to remove UserFederationProvider unless it has no impact<br>
on design of the new providers. We shouldn't sacrifice the<br>
usability/design of the new SPI for the sake of this.<br>
</blockquote>
<br>
With what I got so far, I've written it to be completely backward compatible and allow them to co-exist.<br>
<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">
* We should be careful about changing behavior of LDAP provider as it's<br>
supported in product<br>
</blockquote>
<br>
Honestly, we made a very bad decision to not refactor the federation SPI and to force users to import. It is going to be a really big headache to migrate existing LDAP users to the new LDAP provider. IMO, it is ultra important to stop importing everything.<br>
</blockquote></span>
Maybe I am missing something, but not sure why is it a headache? Is it because of the UUID of user is going to change to new format like f:<PROVIDER-UUID> , so users may not be referenced from the applications with correct UUID? This looks to be a migration issue for all existing federation providers, not just LDAP specific?<span class=""><font color="#888888"><br>
<br>
Marek</font></span><div class=""><div class="h5"><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">
<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">
* JTA - should we support proper JTA transactions for consistency?<br>
<br>
</blockquote>
<br>
Yes, but not all federation providers will be able to take advantage of it, i.e. LDAP.<br>
<br>
Bill<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div></div>