search

joselfonseca / lighthouse-graphql-passport-auth

Add GraphQL mutations to get tokens from passport for https://lighthouse-php.com/
https://lighthouse-php-auth.com/
MIT License
229 stars 56 forks source link

No clear method for authenticating user on asynchronous job queue #119

Closed GregPeden closed 3 years ago

GregPeden commented 3 years ago

I am trying to set up GrqphQL subscriptions and everything is working except for this authorization layer does not work on the job queue. Since it's preferred for subscription broadcasts to be queued, this leads to all broadcasts events generating and "unauthenticated" response. The broadcast actually does proceed but returns a null result to the client, effectively identical to a subscription broadcast event which meant to return null..

If I set Lighthouse to run broadcasts on the main process (no queue), it works as expected.

Importantly, the job queue does correctly invoke the correct user who initiated the broadcast event, it's just that this auth check on the Lighthouse API call fails.

Is there a by-design solution for addressing this? As far as I can discern this package is inherently unable to deal with this case, am I wrong?

joselfonseca commented 3 years ago

This is an interesting use case, I have never actually done it with queues. We used pusher for broadcasting on the main process and then the connected client would be authenticated and it was able to use lighthouse calls without issues at the time. So to answer the question, I don't think there is a by-design solution for this. Of course if you find something that you think should be incorporated in the package to support it I am more than happy to review a PR and discuss it as it may be a use case that shows up in the future. Let me know what you think!

GregPeden commented 3 years ago

Yes as you surmised I am using a Redis broadcaster instead of Pusher but I think the same thing would happen with a Pusher broadcaster if the job is queued.

I'll look in to it.

GregPeden commented 3 years ago

Quick update, it's the "@guard" directive which is tripping and causing the broadcast to fail, because it's looking for an authenticated user explicitly via the auth guard scheduled in the lighthouse.php config. So I am pivoting to resolving this on Lighthouse's end for now.

joselfonseca commented 3 years ago

@SirLamer Great! thanks for the update! Hope you are able to find a solution for your issue.