mirror of
https://github.com/moby/moby.git
synced 2026-01-11 18:51:37 +00:00
f8bd170b2a
Filter-term validation does not belong in the API module. Clients should not be making any assumptions about which terms the daemon understands. Users should not need to upgrade their clients to use filter terms introduced in a newer daemon. Move the network filter validation from the api module into the daemon. Split network.NewFilter into network.NewListFilter and network.NewPruneFilter constructors which validate the filter terms, enforcing the invariant that any network.Filter is a well-formed filter for networks. The network route handlers have been leveraging a hidden 'idOrName' filter term that is not listed in the set of accepted filters and therefore not accepted in API client requests. And it's a good thing that it was never part of the API: it is completely broken and not fit for purpose! When a filter contains an idOrName term, the term values are ignored and instead the filter tests whether either the 'id' or 'name' terms match the Name of the network. Unless the filter contains both 'id' and 'name' terms, the match will evaluate to true for all networks! None of the daemon-internal users of 'idOrName' set either of those terms, therefore it has the same effect as if the filter did not contain the 'idOrName' term in the first place. Filtering networks by id-or-name is a quirky thing that the daemon needs to do to uphold its end of the Engine API contract, not something that would be of use to clients. Fixing up the idOrName filter would necessitate adding it to the list of accepted terms so the filter passes validaton, which would have the side effect of also making the filter available to API clients. Instead, add an exported field to the Filter struct so that daemon code can opt into the internal-only behaviour of having the 'id' term match on either the network Name or ID. Signed-off-by: Cory Snider <csnider@mirantis.com>