Closed Vinksyunit closed 9 months ago
Just noticed https://github.com/laravel/pulse/issues/269, I will have a look to check if issue is indeed the same later today.
Edit: it seems more an issue about detecting the user for the context and not for authenticating Pulse requests.
I'm unable to replicate this problem. Below is what I am using against a fresh laravel application.
I am seeing all the expected logging for both the initial request and subsequent requests. The exception is never thrown.
Can you please create a minimal reproduction for this and we take a closer look?
laravel new bug-report --github="--public"
class AppServiceProvider extends ServiceProvider
{
public function register(): void
{
//
}
public function boot(): void
{
Auth::extend('admin_session', function () {
Log::info('Using auth via custom guard.');
return new class implements AuthGuard {
public function check()
{
return true;
}
public function guest()
{
return false;
}
public function user()
{
return User::first()->setAttribute('from_custom_guard', true);
}
public function id()
{
return $this->user()->id;
}
public function validate(array $credentials = [])
{
return true;
}
public function hasUser()
{
return true;
}
public function setUser(Authenticatable $user)
{
//
}
};
});
Gate::define('viewPulse', function (?User $user) {
if ($user->from_custom_guard !== true) {
throw new Exception('Wrong one!');
}
Log::info('Able to view Pulse.');
return true;
});
}
}
'guards' => [
'web' => [
'driver' => 'session',
'provider' => 'users',
],
'admin' => [
'driver' => 'admin_session',
'provider' => 'users',
],
],
'middleware' => [
'auth:admin',
'web',
Authorize::class,
],
Thanks for the quick reply. I had a look with my team this morning and we identified what's missing here to reproduce. We simplified too much the context of the issue (and we are sorry for that 🙏).
The missing step is that we have a custom Authenticate middleware for admins in order to redirect to another route.
<?php
namespace App\Http\Middleware;
use Illuminate\Auth\Middleware\Authenticate;
use Illuminate\Http\Request;
class AdminAuthenticate extends Authenticate {
protected function redirectTo(Request $request)
{
return '/';
}
}
So our middleware configuration in pulse.php
looks like this :
<?php
use App\Http\Middleware\AdminAuthenticate;
return [
'middleware' => [
AdminAuthenticate:class . ':admin',
'web',
Authorize::class,
],
]
We changed it to this and everything works fine.
<?php
return [
'middleware' => [
'auth:admin',
'web',
Authorize::class,
],
]
As a workaround, we changed the middleware in pulse, so the issue is not as critical for us, but we still think it could be usefull to be able to use custom authentication middlewares in pulse later. Perhaps, something to do with livewire configuration ? I'm not familiar with it.
We will provide you a minimal repo tomorrow to easily reproduce.
I've been able to replicate this issue. Looks like an issue with Livewire.
I'm investigating a fix.
Opened a fix for this one: https://github.com/laravel/pulse/pull/283
I'll close this and we can follow along in that PR.
Pulse Version
v1.0.0-beta9
Laravel Version
10.40.0
PHP Version
8.3.1
Livewire Version
3.3.5
Database Driver & Version
postgres:16-alpine3.19 (Docker linux amd/64)
Description
Working on a solution with two different user's guards, we notice that the POST /livewire/update requests does not use the intended guard for pulse. Indeed, the
auth:other_guard
middleware is set up in the Pulse config file, but it seems that thePOST livewire/update
request does not use the middleware in the pulse config and instead, only theweb
middleware, thus using the default user guard.Steps To Reproduce
Set up a second Auth provider (
admin_session
in this example)Add another user guard in
config/auth.php
.config/pulse.php
) to use the intended guardadmin
guard as intended, whereasPOST livewire/update
uses the defaultweb
guard. It can be easily noticed using theviewPulse
Gate.