This is closely related to #2760 with the same motivation, except that I would like to have a _view_ which transforms (not filters!) a table based on X-Hasura-User-Id. A straightforward solution is to expose session variables in queries under current_setting('hasura.user') similarly to how it's done in mutations. In fact, the change implementing this is simple:
--- a/server/src-lib/Hasura/GraphQL/Transport/HTTP.hs
+++ b/server/src-lib/Hasura/GraphQL/Transport/HTTP.hs
@@ -50,7 +50,7 @@ runHasuraGQ reqId query userInfo resolvedOp = do
E.ExOpQuery tx genSql -> do
-- log the generated SQL and the graphql query
liftIO $ logGraphqlQuery logger $ QueryLog query genSql reqId
- runLazyTx' pgExecCtx tx
+ runLazyTx pgExecCtx $ withUserInfo userInfo tx
E.ExOpMutation tx -> do
-- log the graphql query
liftIO $ logGraphqlQuery logger $ QueryLog query Nothing reqId
Still, I wanted to make sure the idea itself is sound before opening a PR.
@dshynkev
I would like to have a view which transforms (not filters!) a table based on X-Hasura-User-Id
You can do this using a function soon. However, we can't add session variables to the transaction local 'hasura.user' parameter in case of a query as it would break the current subscriptions backend (which fetches the data of several instances of a subscription in a single query to Postgres). Would #3143 work for you?
My bad, wasn't aware of how subscriptions worked. Will it be possible to use functions with session arguments to define scalar computed columns? If so, then that's perfect for my needs. Otherwise it's a bit troublesome because the input columns contain sensitive data and should not be exposed in Hasura.
Will it be possible to use functions with session arguments to define scalar computed columns?
@dshynkev That's a very good question. Currently, no. But it is not hard to add. Please update the issue title corresponding to your requirement, a feature request. We'll definitely look into this.
@rakeshkky Does #3143 resolve this issue, or is there something else that still needs to be done?
@lexi-lambda No. #3143 only support root SQL function queries to access session information. This needs to be done.
Any chance we could get this in? I've got a use case I cannot use ACL for because I don't want to expose that data to users, but I need to use a table as a filter. This is all based on the currently logged in user, which would make this change perfect!
Is there any progress on this feature? I have a use-case that I can't find any better solutions:
I have a posts and users table, then I have a bookmarks table which connects these two. I want to define a isBookmarked computed property on posts, which needs to access current user id inside it's function definition. Without this feature, my only solution is to set permissions on bookmarks and connect it with posts, graphql query will be longer and it's result will contain a field which is always an array of zero or one item.
Yes, this is high up in our priority list. Actually, it was being tracked here: https://github.com/hasura/graphql-engine/issues/3846
I am closing this issue in favour of #3846 (as more eyeballs there)