Problem
Using DTO authorizer, I'm able to query filtered collections based on user role.
Role Admin sees everything but role User sees only his own records.
Now when both subscribe to updates and Admin updates record, User does NOT get notified and vice versa, because they have different authorize filters.
So Admin will publish event eventName-A on update and is subscribed to the same event, but User will publish and subscribe to eventName-B.
That way implementation doesn't leak data to user without proper role BUT not everyone gets notified even if they should.
Solution
This can be solved by using existing applyFilter on subscription iterator inside subscription resolver method.
My current solution
I'm currently monkey-patching these methods with custom decorator (cause overriding all methods with proper types is just too much, I'm already overriding some).
Would you be interested in PR?
It would very much helped me, if this could be included in library. From my perspective, this is how subscription should work.
I'll be willing to make PR if there is more interest in this. But my hope is it would be merged if possible, not forgotten :)
Problem Using DTO authorizer, I'm able to query filtered collections based on user role. Role
Admin
sees everything but roleUser
sees only his own records. Now when both subscribe to updates andAdmin
updates record,User
does NOT get notified and vice versa, because they have different authorize filters.Original solutions for that was done in https://github.com/TriPSs/nestjs-query/commit/d2f857f73540ee400f5dcc79cbb25dfba81c2963 It introduced separate PubSub event using original eventName and authorizeFilter https://github.com/TriPSs/nestjs-query/blob/1568cfde3652d0ebf2fc1c7e6e671a047d06e517/packages/query-graphql/src/resolvers/helpers.ts#L39
So
Admin
will publish eventeventName-A
on update and is subscribed to the same event, butUser
will publish and subscribe toeventName-B
. That way implementation doesn't leak data to user without proper role BUT not everyone gets notified even if they should.Solution This can be solved by using existing
applyFilter
on subscription iterator inside subscription resolver method.How this could look? Assume this helper exists:
Now we can filter results from
pubSub.asyncIterator(eventName)
. This is how implementation ofupdateOneSubscription
could look:My current solution I'm currently monkey-patching these methods with custom decorator (cause overriding all methods with proper types is just too much, I'm already overriding some).
Would you be interested in PR? It would very much helped me, if this could be included in library. From my perspective, this is how subscription should work. I'll be willing to make PR if there is more interest in this. But my hope is it would be merged if possible, not forgotten :)