Closed jeovajr closed 1 year ago
Hey, @jeovajr 👋 Thanks for reporting this! I'm unfamiliar with Telescope offhand, and I don't think it's something we've ever tested against. Let me look into it and see if we can get that working for you.
Hello @evansims and @jeovajr.
I've found the same issue.
My solution was setting the TELESCOPE_EVENT_WATCHER=false
on my .env.
But it'll be better to be able to watch events.
Thanks for the extra details, @martingetzel; that workaround might help in troubleshooting the cause of this issue.
I experience the same problem with Laravel 10, auth0 7.8 and a custom user repository, too. The error manifested as a 502 Bad Gateway error.
I changed the telescope config file as follows to get rid of this error:
Watchers\EventWatcher::class => [
'enabled' => env('TELESCOPE_EVENT_WATCHER', true),
'ignore' => [
\Auth0\Laravel\Events\Configuration\BuiltConfigurationEvent::class,
\Auth0\Laravel\Events\Configuration\BuildingConfigurationEvent::class,
],
],
/*
Disabled because it causes a Bad Gateway (502) error when used with
Auth0 and CustomUserRepository. It seems to be caused by some kind of
loop when executing `Auth::hasUser()` inside `Telescope::record`.
*/
Watchers\QueryWatcher::class => [
'enabled' => env('TELESCOPE_QUERY_WATCHER', false),
'ignore_packages' => true,
'slow' => 100,
],
👋 Just wanted to update — I'm still investigating this. I can reproduce it with the out-of-the-box Laravel template application, with the SDK and Telescope installed.
👋 I've just released 7.11.0, which includes a number of workarounds to provide better compatibility with Telescope. It was a bit of a tricky issue to address. There's a chicken and an egg situation there. I think I was able to apply workarounds that should address most use cases, however.
I've added a new document, https://github.com/auth0/laravel-auth0/blob/main/docs/Telescope.md, which offers guidance/workarounds that applications can implement if their custom integration/code results in infinite loops going forward.
Thanks for bringing this to my attention, and I hope 7.11 fully resolves things for you.
Sorry if I'm reopening this but I have the same issue on the API side. I'm trying to fix it but I can't manage to find a way.
@isalcedo
Can confirm the same problem with the api guard, session guard is working fine with the latest package release
For me, adding these three events to the ignored events list fixed the issue
Watchers\EventWatcher::class => [
'enabled' => env('TELESCOPE_EVENT_WATCHER', true),
'ignore' => [
\Auth0\Laravel\Events\Configuration\BuiltConfigurationEvent::class,
\Auth0\Laravel\Events\Configuration\BuildingConfigurationEvent::class,
// Added these three
\Auth0\Laravel\Events\TokenVerificationAttempting::class,
\Auth0\Laravel\Events\TokenVerificationFailed::class,
\Auth0\Laravel\Events\TokenVerificationSucceeded::class
],
],
update:
Also needed to disable the query and redis watcher altogether, which is not great for debugging, but it fixes auth0 for now.
auth0: v7.12.0
I added above mentioned events to ignore, but it did not fixed eather, so i added couple more Auth0 Events and it stopped infinite loop
'ignore' => [
\Auth0\Laravel\Events\TokenVerificationAttempting::class,
\Auth0\Laravel\Events\TokenVerificationFailed::class,
\Auth0\Laravel\Events\TokenVerificationSucceeded::class,
\Auth0\Laravel\Events\Configuration\BuildingConfigurationEvent::class,
\Auth0\Laravel\Events\Configuration\BuiltConfigurationEvent::class,
\Auth0\Laravel\Events\Middleware\StatefulMiddlewareRequest::class,
\Auth0\Laravel\Events\Middleware\StatelessMiddlewareRequest::class,
\Auth0\Laravel\Events\AuthenticationSucceeded::class,
\Auth0\Laravel\Events\LoginAttempting::class,
\Auth0\Laravel\Events\AuthenticationSucceeded::class,
],
still having the same problem :( no effect.
What worked for me were this:
Watchers\EventWatcher::class => [
'enabled' => env('TELESCOPE_EVENT_WATCHER', true),
'ignore' => [
\Auth0\Laravel\Events\Configuration\BuiltConfigurationEvent::class,
\Auth0\Laravel\Events\Configuration\BuildingConfigurationEvent::class,
\Auth0\Laravel\Events\Middleware\StatelessMiddlewareRequest::class,
\Auth0\Laravel\Events\Middleware\StatefulMiddlewareRequest::class,
\Auth0\Laravel\Events\AuthenticationSucceeded::class,
\Auth0\Laravel\Events\AuthenticationFailed::class,
\Auth0\Laravel\Events\LoginAttempting::class,
\Auth0\Laravel\Events\TokenVerificationFailed::class,
\Auth0\Laravel\Events\TokenExpired::class,
\Auth0\Laravel\Events\TokenRefreshFailed::class,
\Auth0\Laravel\Events\TokenRefreshSucceeded::class,
\Auth0\Laravel\Events\TokenVerificationAttempting::class,
\Auth0\Laravel\Events\TokenVerificationSucceeded::class,
],
],
Checklist
docs
directory and have not found a solution.Laravel Version
10
SDK Version
Other (specify below)
PHP Version
PHP 8.2
Description
SDK version 7.9
I'm trying to upgrade from SDK 7.6 to 7.9 and I'm finding some issues.
I originally thought I had found the solution, because I detected a infinite loop on my logging service.
Basically, on my logging service, I check if the user is authenticated, if so, I add some information related to the user on the log entry.
My application requires a custom user repository.
So, on the user repository, I had some logs, which where creating an infinite loop when the logging service checked for auth()->check(). It calls the user repository, which tries to log, which checks for the user authentication, which loops indefinitely.
I fixed my issue by adding some extra parameters to the log call, so I can basically ignore the user just when I log from the user repository.
But then, I found that the same issue also happens with
Laravel Telescope
.On the custom repository, a query is always executed (on time to create the user, then to fetch it from DB).
This triggers the some watchers from
Laravel Telescope
.On Telescope's
record
method, used by a bunch of watchers, there's this section:The
Auth::hasUser()
call creates the same problem, since it will create a infinite loop on the user repository when trying to fetch the user from the DB (QueryWatcher), or from any other watcher that is being triggered.Since it's just for logging, it will ignore any exceptions thrown there. So I guess the solution would be to have some extra validations on the Auth0 guards, to throw a exception in case there's any kind of loop from the user repository, or return false for Auth::check()/Auth::hasUser() calls when the user repository has not yet finished providing the actual user.
My workaround at this moment is to disable telescope, but it's a very important tool we use frequently, so we need to be able to use it.
How can we reproduce this issue?