Graphql-engine: [Feature request] Disable root level list / _by_pk queries on any table

Created on 19 Jan 2020  Â·  6Comments  Â·  Source: hasura/graphql-engine

Hi Hasura team,

Summary

Right now it is possible to disable aggregation queries per table & role.
image

I would like to be able to disable top level list and primary key access in the same fashion.

image
If I can already rename these root fields, I should be able to disable them entirely too.

Use case (general)

Say I have a table of sensitive information that I would like a non-authenticated / public user to be able to access if they know the secret primary key.

Right now, they can use secret_data_by_pk(id: "some-uuid") { ... } and the data is safely accessed.

However, users can also just secret_data { ... } and enumerate all the sensitive information that doesn't belong to them.

Use case (specific example)

For me, this is would hugely simplify permissions checks, as I simply wouldn't have to write them in many cases. I'm attaching Hasura to an existing database + web server that currently separates data into many smaller tables.

Specifically in my use case, I have a purchases table, which has a clientId and customerId. The table has a permission check of clientId = x-hasura-client-id. It then joins against customers, which joins on contactInfoId against contactInfos.
customers has a clientId I could do a permissions check against, but contactInfos does not. This is important, because right now in my current server, I only ever join with contactInfos if I already have a valid customer row. I can only have access to a customer object if I have access to the purchase.

This means that, if I could only go via client { purchases { customer { contactInfo { name } } } }, all customer and contact information would be secure.

However, there is a non-optional top level contactInfos query generated by Hasura, which lets an authenticated client list all contact infos. This means I now have to write a complex custom permission on contactInfos to ensure security.
This is a problem as this is just one example of this in my existing code-base, I would need to do this repetitive and seemingly unnecessary task for a large number of tables to safely expose them.

Possibly related issues

I believe this issue is a simpler version of what the following two are asking:
https://github.com/hasura/graphql-engine/issues/3544
https://github.com/hasura/graphql-engine/issues/3436

Extra info

I'm using Hasura v1.0.0.
Also, Hasura is absolutely brilliant and I'm enjoying using it very much ✨

server enhancement longterm triag2-needs-rfc

Most helpful comment

All 6 comments

you can just set the permission anonymous users to allow only selecting items which matches the secret passed as a header.

secret: { _eq:  x-hasura-known-secret }

Or did I missed your problem?

@webdeb that looks like a possible workaround, but it is still a cumbersome and indirect way of achieving the result.

@webdeb headers are not automatically made available as session variables. they need to be put in the access token, and therefore hard to change which each request.

https://github.com/hasura/graphql-engine/issues/2951

Or did I miss something?

@tirumaraiselvan I think @franciscolourenco would also be helped by #1601 that we were discussing today?

Closing this issue in favour of #696

Was this page helpful?
0 / 5 - 0 ratings

Related issues

EmrysMyrddin picture EmrysMyrddin  Â·  3Comments

Fortidude picture Fortidude  Â·  3Comments

egislook picture egislook  Â·  3Comments

cpursley picture cpursley  Â·  3Comments

tirumaraiselvan picture tirumaraiselvan  Â·  3Comments