Authentication and DQL schemas

Is it possible to define something like @auth for DQL schemas, rather than GraphQL schemas?

If not:

  • Is that something that’s planned to be added in the near future?
  • What is the recommended way to handle authentication in DQL (as part of a query block within an upsert block)?

Thanks.

Use GraphQL and then use DQL to access data in the underlying schema

What about if I want to define features available to DQL schemas only (like @reverse / @lang)? Don’t I need to define the schema in DQL? Doesn’t that then mean the GraphQL interface won’t work properly?

What about if I want to define features available to DQL schemas only (like @reverse / @lang)? D

You can access the DQL schema in Ratel. Then you can update your schemas there.

Doesn’t that then mean the GraphQL interface won’t work properly?

This, I am not so sure.

If you want, you can send me an example schema and I can test it out for you

I’ve not got a particular schema in mind yet - I’m still trying to work out whether defining the schema using GraphQL or DQL makes more sense.

Thinking about it, @hasInverse is likely to do everything that I’d want @reverse to do (and more), so that’s not a big issue. I’m thinking that using a GraphQL schema is probably going to be the better choice.

To clarify:

If you have @auth declarations defined on various types, if you’re accessing the data using DQL through the GraphQL interface (e.g. using a @custom declaration), will all the @auth definitions be adhered to?

If you have @auth declarations defined on various types, if you’re accessing the data using DQL through the GraphQL interface (e.g. using a @custom declaration), will all the @auth definitions be adhered to?

No. They are not adhered to. If you can get a client connecting with it, then you can bypass the graphql layer’s auth

To clarify, I’m referring to using the /graphql interface, and putting the DQL in a @custom(dql: …) declaration - not the /query interface.

Is there therefore no way to have any kind of authentication checks when using DQL, even within @custom directives?

Is @auth only adhered to on the generated functions like queryType, addType, deleteType …?

Nope.

No.

Using pure DQL(no GraphQL) you should build your own API to handle this.

DQL and GraphQL won’t interact in the two ways. DQL will change if you modify the GraphQL Schema. But will modify nothing if you use some DQL feature in the DQL context. But also, never modify by hand the schema made by the GraphQL feature. Reverse and Lang aren’t supported at all in the GQL part. HasInverse is a totally different story. I mean, not the same as reverse.

I think the GraphQL team is working to make GQL Auth to work with the custom directive. Have you tried lambdas?

Try lambda. @abhimanyusinghgaur do we have auth with custom or lambda?

Auth should protect all basic GQL-CRUD.

Cheers.

1 Like

We currently don’t have @auth on custom or lambda but we are working on RFC for @auth on custom DQL query.

2 Likes

@MichelDiz - Thanks for all that.

Any plans to include @reverse in GraphQL?

Not sure, I feel that is a job for the GraphQL Foundation. As the concept of reverse edge with tilde notation is DQL only. Do you have any suggestion on how to implement it?

If you don’t want to include the tilde notation (which I presume would break GraphQL syntax rules), how about using something like this:

  1. Define @reverse in the schema like in DQL schemas
  2. On the reverse predicates, use the name without a tilde and a @reverse directive, e.g. with this example
~wife
# becomes
wife @reverse
  1. Return results like in DQL with the tilde in front of it, or if the tilde will break GraphQL syntax rules for JSON returns, then return something like [predicate_name]__reverse or _reverse[predicate_name] (or [predicate_name]@reverse if that doesn’t break syntax rules).

Note: In 2 you could use a distinct directive like @reverseLookup or @reverseQuery, but since @reverse doesn’t take any arguments, it makes sense to me to keep it as clean as possible.

I think whatever is achieved by @reverse can be achieved by @hasInverse, maybe in some cases by changing the schema bit. Can you give example where that is not the case?

I basically came to the same conclusion, and I think @hasInverse is more useful to me than @reverse anyway.