Query sever timestamps in GraphQL?

Issues GraphQL
,
38

Thank you @dpeek!

We really really appreciate all your work and efforts on this! Not only is this a timestamps new feature, but it is a default value new feature which is awesome!!!

This was incredible, and we need more users contributing like you!

Security Problem

That being said…

For anyone who finds this after 21.12 is released, you will not be able to secure your fields updatedAt and createdAt until after the update-after-auth, which is hopefully in the next version 22.0X… ?

As of Right now, if you want to secure a field with add rule, you can do an @auth directive like so:

type Post @auth(
  add: { rule: "query { queryPost(filter: { not: { has: [createdAt, updatedAt] } } { id }" }
) {
  ...
  createdAt: DateTime @default(add: { value: "$now" })
  updatedAt: DateTime @default(update: { value: "$now" })
}

However, if you do this with update rule rule:

type Post @auth(
  update: { rule: "query { queryPost(filter: { not: { has: [createdAt, updatedAt] } } { id }" }
) {
  ...
  createdAt: DateTime @default(add: { value: "$now" })
  updatedAt: DateTime @default(update: { value: "$now" })
}

It evaluates the data before it is entered into the database, not after the mutation, like the add rule does… so, we need update-after-auth.

The @auth directive was really built for RBAC and ABAC using claims inside your Authentication Token. That being said, the @auth directive is SOOO much more powerful, and can do things like Field Level @auth — not to mention it fixes the security vulnerability of being able to create a new node owned by anyone else.

Field Security for Now - field level @auth?

You can only really secure a field differently by creating a new nested field. Usually you want to give your users the ability to create a post / tweet / comment, but now allow them to edit the date the post was created or updated, as this should be automatic and secure.

You can do this now (before v21.12) by using Post Lambda Webhooks and creating a nested field. This method is definitely a hack, and you have to disable @hasInverse, but it works as expected.

However, I cannot seem to fathom a way to secure this new @default directive. If we use nested nodes, and the nested node is secure from add and update, we won’t be able to add or edit it at all differently. The only way would be to use a lambda, which would get us back to my method.

So, if security is important to you, use my method, or wait for some type of field-level-auth security, like the update-after-auth feature and bug fix.

Maybe the actual docs will cover a security method for these fields and I am wrong. Maybe someone has another hack we will be able to do immediately (let us know!)

That being said, the @default directive and all the hard work from @dpeek are very useful NOW, and we greatly appreciate it!

J

1 Like