user-record: also support "aliases" in the "status" section of user records
Some user record providers might want to implement case-insensitive user
record matching, or other forms of non-normalized matching. So far
uderdb didn't allow that, because client's typically revalidate the
returned user records against the search keys (at least our clients do)
– they check if the search user name is actually part of the user record
and its aliases.
In order to support such lookups we thus need to allow the looup keys to
be part of the user record, but also not be persisted in it, because
the number of casings/spellings of a username might be ridiculously
high.
A nice way out is to allow "aliases" not only in the main part of the
record, but also in the "status" part, that contains information
dynamically determined at query time. We can insert a second "aliases"
field there, which the parser will then merge with the primary "aliases"
field, but the existing rules around "status" ensure tha the data is
never persisted.
Follow-up: e2e1f38f5a
This commit is contained in:
committed by
Luca Boccassi
parent
ad39648171
commit
170d7d49f5
@@ -872,6 +872,18 @@ sub-object of the top-level user record object is keyed by the machine ID,
|
||||
which points to the object with the fields defined here.
|
||||
The following fields are defined:
|
||||
|
||||
`aliases` → An array of strings, each being a valid UNIX user name. This is
|
||||
similar to the top-level field of the same name. The purpose of this field is
|
||||
to allow user record providers to dynamically insert additional alias names
|
||||
into the user record, depending on the precise query. This is useful to
|
||||
implement case-insensitive user names (or support for similar non-normalized
|
||||
user record naming), as it allows the provider to insert the precise
|
||||
casing/spelling of the user name used for the look-up in the record data,
|
||||
without this being part of the persisted record. Note that clients doing a
|
||||
look-up typically re-validate user records against the lookup keys they
|
||||
provided, hence it's essential that any dynamic alias name appears in the
|
||||
user record, without this being part of the persistent part of the record.
|
||||
|
||||
`diskUsage` → An unsigned 64-bit integer.
|
||||
The currently used disk space of the home directory in bytes.
|
||||
This value might be determined in different ways, depending on the selected storage mechanism.
|
||||
|
||||
@@ -1403,6 +1403,7 @@ static int dispatch_status(const char *name, sd_json_variant *variant, sd_json_d
|
||||
{ "fallbackHomeDirectory", SD_JSON_VARIANT_STRING, json_dispatch_home_directory, offsetof(UserRecord, fallback_home_directory), 0 },
|
||||
{ "useFallback", SD_JSON_VARIANT_BOOLEAN, sd_json_dispatch_stdbool, offsetof(UserRecord, use_fallback), 0 },
|
||||
{ "defaultArea", SD_JSON_VARIANT_STRING, json_dispatch_filename, offsetof(UserRecord, default_area), 0 },
|
||||
{ "aliases", SD_JSON_VARIANT_ARRAY, json_dispatch_user_group_list, offsetof(UserRecord, aliases), SD_JSON_RELAX },
|
||||
{},
|
||||
};
|
||||
|
||||
|
||||
Reference in New Issue
Block a user