On Thu, Feb 26, 2015 at 12:04:03PM +0100, Pavel Březina wrote:
On 02/25/2015 08:13 PM, Jakub Hrozek wrote:
>==== Responder <-> Data Provider communication ====
>The request between the responders and the Data Provider is driven by a
>string filter, formatted as follows:
>{{{
> type:value:extra
>}}}
>Where `type` can be one of `name`, `idnumer` or `secid`. The `value` field
>is the username, ID number or SID value and extra currently denotes either
>lookup with views or lookup by UPN instead of name.
>
>To support the wildcard lookups, we have two options here - add a new
>`type` option (perhaps `wildcard_name`) or add another `extra_value`.
>
>Adding a new `type` would be easier since it's just addition of new code, not
>changing existing code. On the backend side, the `type` would be typically
>handled together with `name` lookups, just sanitize the input differently.
>The downside is that if we wanted to ever allow wildcard lookups for
>anything else, we'd have to add yet another type. Code-wise, adding a new
>type would translate to adding new values for the `sss_dp_acct_type` enum which
>would then print the new type value when formatting the sbus message.
>
>The other option would be to allow multivalued `extra` field:
>{{{
> type:value:extra1:extra2:...:extraN
>}}}
>However, that would involve changing how we currently handle the `extra`
>field, which is higher risk of regressions. Also, the back ends can
>technically be developed by a third party, so we should be extremely careful
>about changing the protocol between DP and providers. Since we don't expect
>to allow any other wildcard requests than by name yet, I'm proposing to
>go with the first option and add a comment to the code to change to using
>the extra field if we need wildcard lookups by another attribute.
In the future, I'd very much like to refactor current data provider D-Bus
interface to stop using types that denotes meaning and format of incoming
message and start using separate methods instead.
Would it be possible/simple enough to create a new method for this call?
I think it would be better to convert them all. Otherwise we would again
end up with some calls using the old scheme and some using the new one.
>
>=== Configuration changes ===
>None.
There should be parameter to limit number of looked up records. See:
https://fedorahosted.org/sssd/wiki/DesignDocs/DBusUsersAndGroups
# Overwies of the solution
# Configuration changes
OK, I totally forgot about that..
Do these changes sound good to you?
https://fedorahosted.org/sssd/wiki/DesignDocs/WildcardRefresh?action=diff...