The entity the input will be applied to.
Fails open on a missing user. With no user the gate does nothing, so server-internal
code, and a client with no per-call user, are unaffected. A server-side transport applying a
request's input must therefore pass the requesting user, or nothing is checked.
The client input. Never modified.
The caller. When absent the gate does nothing (see above).
Optionaloptions: ClientInputGateOptions
The write-side gate for transports that apply client input with
SetMany: throws a FieldSecurityError when the input carries a key the caller may not send.Applies only to a caller who is denied at least one field on the entity. For that caller, a key is refused when it names a field they cannot READ, or when it names no field at all; both get the identical FieldSecurityClientInputMessage. Treating unknown keys the same way is what keeps the refusal from revealing whether a column exists: refusing only denied keys would answer "does
Salaryexist?" for any key a caller cares to try.Rejection rather than silent removal: a client holding a denied value can only have fabricated it, because no response it received contained one, so there is no legitimate request to save.
Keys in ClientInputTransportKeys, and any in
options.additionalAllowedKeys, are accepted. Matching is case- and whitespace-insensitive, by Name and CodeName, likeSetMany. Callers who are denied nothing, or input for an entity without field security, are unaffected, soSetMany's ordinary handling of unknown keys still applies to them.