Authentication and DQL schemas

[eugaia]

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.

[chewxy]

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

[eugaia]

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?

[chewxy]

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

[eugaia]

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:

@chewxy

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

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?

[chewxy]

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

[eugaia]

@chewxy

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?

[eugaia]

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

[MichelDiz]

@eugaia

Is it possible to define something like @auth for DQL schemas

Nope.

@eugaia

Is that something that’s planned to be added in the near future?

No.

@eugaia

What is the recommended way to handle authentication in DQL

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

@eugaia

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

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.

@eugaia

will all the @auth definitions be adhered to?

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

@eugaia

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

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

@eugaia

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

Auth should protect all basic GQL-CRUD.

Cheers.

[JatinDevDG (Jatin Dev)]

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

WIP: Auth rules custom DQL query

Motivation Support for @auth rules with @custom DQL query. User Impact Users will now be able to use @auth rules provided in the Graphql schema with @custom DQL queries also. This will be a major feature in the @custom DQL and will enhance the user experience. Implementation Overview Since @auth rules are defined in the GraphQL schema along with the type definition, we need to apply them to the DQL query based on the type queried in the DQL query. The problem reduces to finding the type of the…

[eugaia]

@MichelDiz - Thanks for all that.

Any plans to include @reverse in GraphQL?

[MichelDiz]

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?

[eugaia]

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

3. 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.

[JatinDevDG (Jatin Dev)]

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?

[eugaia]

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