
Product
Redesigned Repositories Page: A Faster Way to Prioritize Security Risk
Our redesigned Repositories page adds alert severity, filtering, and tabs for faster triage and clearer insights across all your projects.
@liteflow/postgraphile-plugin-connection-filter
Advanced tools
Filtering on PostGraphile connections
Adds a powerful suite of filtering capabilities to a PostGraphile schema.
Warning: Use of this plugin with the default options may make it astoundingly trivial for a malicious actor (or a well-intentioned application that generates complex GraphQL queries) to overwhelm your database with expensive queries. See the Performance and Security section below for details.
Requires PostGraphile v4.5.0 or higher.
Install with:
yarn add postgraphile postgraphile-plugin-connection-filter
CLI usage via --append-plugins
:
postgraphile --append-plugins postgraphile-plugin-connection-filter -c postgres://localhost/my_db ...
Library usage via appendPlugins
:
import ConnectionFilterPlugin from "postgraphile-plugin-connection-filter";
// or: const ConnectionFilterPlugin = require("postgraphile-plugin-connection-filter");
const middleware = postgraphile(DATABASE_URL, SCHEMAS, {
appendPlugins: [ConnectionFilterPlugin],
});
By default, this plugin:
setof
, which can result in expensive operations.To protect your server, you can:
connectionFilterAllowedFieldTypes
and connectionFilterAllowedOperators
options to limit the filterable fields and operators exposed through GraphQL.connectionFilterComputedColumns: false
to prevent filtering on computed columns.connectionFilterSetofFunctions: false
to prevent filtering on functions that return setof
.connectionFilterArrays: false
to prevent filtering on List fields (Postgres arrays).Also see the Production Considerations page of the official PostGraphile docs, which discusses query whitelisting.
This plugin supports filtering on almost all PostgreSQL types, including complex types such as domains, ranges, arrays, and composite types. For details on the specific operators supported for each type, see docs/operators.md.
See also:
geography
/geometry
columnstsvector
columnsnull
and empty objectsBy default, this plugin will throw an error when null
literals or empty objects ({}
) are included in filter
input objects. This prevents queries with ambiguous semantics such as filter: { field: null }
and filter: { field: { equalTo: null } }
from returning unexpected results. For background on this decision, see https://github.com/graphile-contrib/postgraphile-plugin-connection-filter/issues/58.
To allow null
and {}
in inputs, use the connectionFilterAllowNullInput
and connectionFilterAllowEmptyObjectInput
options documented under Plugin Options. Please note that even with connectionFilterAllowNullInput
enabled, null
is never interpreted as a SQL NULL
; fields with null
values are simply ignored when resolving the query.
When using PostGraphile as a library, the following plugin options can be passed via graphileBuildOptions
:
Restrict filtering to specific operators:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterAllowedOperators: [
"isNull",
"equalTo",
"notEqualTo",
"distinctFrom",
"notDistinctFrom",
"lessThan",
"lessThanOrEqualTo",
"greaterThan",
"greaterThanOrEqualTo",
"in",
"notIn",
],
},
});
Restrict filtering to specific field types:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterAllowedFieldTypes: ["String", "Int"],
},
});
The available field types will depend on your database schema.
Enable/disable filtering on PostgreSQL arrays:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterArrays: false, // default: true
},
});
Enable/disable filtering by computed columns:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterComputedColumns: false, // default: true
},
});
Consider setting this to false
and using @filterable
smart comments to selectively enable filtering:
create function app_public.foo_computed(foo app_public.foo)
returns ... as $$ ... $$ language sql stable;
comment on function app_public.foo_computed(foo app_public.foo) is E'@filterable';
Use alternative names (e.g. eq
, ne
) for operators:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterOperatorNames: {
equalTo: "eq",
notEqualTo: "ne",
},
},
});
Enable/disable filtering on related fields:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterRelations: true, // default: false
},
});
Enable/disable filtering on functions that return setof
:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterSetofFunctions: false, // default: true
},
});
Consider setting this to false
and using @filterable
smart comments to selectively enable filtering:
create function app_public.some_foos()
returns setof ... as $$ ... $$ language sql stable;
comment on function app_public.some_foos() is E'@filterable';
Enable/disable filtering with logical operators (and
/or
/not
):
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterLogicalOperators: false, // default: true
},
});
Allow/forbid null
literals in input:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterAllowNullInput: true, // default: false
},
});
When false
, passing null
as a field value will throw an error.
When true
, passing null
as a field value is equivalent to omitting the field.
Allow/forbid empty objects ({}
) in input:
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterAllowEmptyObjectInput: true, // default: false
},
});
When false
, passing {}
as a field value will throw an error.
When true
, passing {}
as a field value is equivalent to omitting the field.
When building the "many" relationship filters, if this option is set true
then we will use the "list" field names rather than the "connection" field
names when naming the fields in the filter input. This would be desired if you
have simpleCollection
set to "only"
or "both"
and you've simplified your
inflection to omit the -list
suffix, e.g. using
@graphile-contrib/pg-simplify-inflector
's pgOmitListSuffix
option. Use this
if you see Connection
added to your filter field names.
postgraphile(pgConfig, schema, {
graphileBuildOptions: {
connectionFilterUseListInflectors: true, // default: false
},
});
query {
allPosts(filter: {
createdAt: { greaterThan: "2021-01-01" }
}) {
...
}
}
For an extensive set of examples, see docs/examples.md.
To establish a test environment, create an empty PostgreSQL database with C collation (required for consistent ordering of strings) and set a TEST_DATABASE_URL
environment variable with your database connection string.
createdb graphile_test_c --template template0 --lc-collate C
export TEST_DATABASE_URL=postgres://localhost:5432/graphile_test_c
yarn
yarn test
FAQs
Filtering on PostGraphile connections
The npm package @liteflow/postgraphile-plugin-connection-filter receives a total of 1 weekly downloads. As such, @liteflow/postgraphile-plugin-connection-filter popularity was classified as not popular.
We found that @liteflow/postgraphile-plugin-connection-filter demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 3 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Product
Our redesigned Repositories page adds alert severity, filtering, and tabs for faster triage and clearer insights across all your projects.
Security News
Multiple deserialization flaws in PyTorch Lightning could allow remote code execution when loading untrusted model files, affecting versions up to 2.4.0.
Security News
NVD now marks all pre-2018 CVEs as "Deferred," signaling it will no longer enrich older vulnerabilities, further eroding trust in its data.