-
-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to replace nodeId
creation logic for specific or all types
#2332
Comments
You're right that the NodeID needs read and write capabilities - or encode and decode more specifically. Fortunately; we built that functionality right in! We have:
You can also add your own codecs by creating a plugin like one of these. The issue is that when we register a table we always register it using the crystal/graphile-build/graphile-build-pg/src/plugins/PgTableNodePlugin.ts Lines 158 to 161 in 6401dea
However, this needn't be the case. You could add a smart tag to change the encoding, and do something like: codec:
build.getNodeIdCodec(
codec.extensions?.tags?.nodeIdCodec
?? firstSource?.extensions?.tags?.nodeIdCodec
?? build.options?.defaultNodeIdCodec
?? 'base64JSON'
), If you were to do so, I'd want to see tests showing this working for all the expected places:
Ideally you could reuse a load of the existing tests and just set a global I'd absolutely love to see this functionality, but it's incredibly low priority for me. I'd love to see some really cool ID codecs, such as ones that perform encryption/decryption, or ones that do Slack-style GUID prefixes to indicate the type of resource. |
Feature description
It would be very helpful to be able to replace the logic how
nodeId
is generated for tables or any other autogenerated resources. This will allow us to encrypt or mask restricted content in the nodeId. Which will be especially useful for the projects that are migrating to postgraphile.Motivating example
Example:
When a
resource.primary_key
is a restricted information, we want to return to the user the primary key, but encrypted, so only the server can decrypt the value, which will allow us to mask the data but the server will be able to understand what have been masked. In a system where there is already a large code designed around the idea thatresource.primary_key
is a restricted information, the only thing that is missing is to also hide it in thenodeId
. It's possible to introduce a new resource with a primary key which is not related to the original resource and also add a relation between those 2 resources that only the server can access, but it can be easily avoided by allowing us to change the logic of generating and reading thenodeId
.Breaking changes
I'm not await what this will break, but I guess that internally, postgraphile is using the content of the
nodeId
, so if we are adding an option to replace the logic, maybe we will also need an API which will return the data postgraphile needs? LikeSupporting development
I [tick all that apply]:
The text was updated successfully, but these errors were encountered: