Regarding guard_name

[kamov]

There is written in Usage section:

you will also need to add protected $guard_name = 'web'; as well to that model or you would get an error

But if we put guard_name = web, and the model it's used also by "api" for example, then how it can work?

Thanks

[drbyte]

Are you using this package to actually grant different permissions based on the guard? Or are your app's roles/permissions guard-agnostic?

I usually find that people actually need no different roles/permissions at the per-guard level, and the only reason they're specifying guards at all is because v2 of this package kinda forces you into it.
Is that true for you too?

Note: v1 of this package doesn't force anything about guards, but is less polymorphic in that it only works with the primary user model specified in config('auth.model').

[kamov]

Thanks for your reply.

I got your point, and yes I understand that it can work also a global namespace for all guard.

I am implementing this because there is this feature.

I think that is also nice to have it, since many permissions for admin side like for example manage settings is not required for frontend.

But is also true that some are shared, like for example create articles is shared on admin and frontend.

Would be good that if guard_name is null, then it can be shared between guard, and if specified, then is only per guard.

But I didn't yet understand regarding my first question, if we specify the guard_name in model, then how it can be shared between all guard?

[drbyte]

But I didn't yet understand regarding my first question, if we specify the guard_name in model, then how it can be shared between all guard?

The only way I've done that is create a separate model for the different guard.

(This package uses the guard-defined model as first priority, overriding any middleware guard or config guard. Changing that to make the config setting override it is a breaking change which we won't do in a minor point release. And in fact we're largely decided on dropping guard-specific rules inside this package since they can pretty much be controlled at the app level without requiring dynamic control using db storage. Hence my questions above.)

[kamov]

Thanks for information regarding future change.

I don't see the point to have separated model per guard, since it will be just the exact same copy with just different variable value.

Not sure also why remove it, since is there, could be just possible to disable, as I understand, by keeping guard_name = null, am I right?

Or instead of single guard_name, could be an array of guard like guard_name = ['api', 'admin', 'web'];

I spent already weekend integrating the guard, by making also seed script with all my permissions per guard. I am not sure now if keep them or refactor without guard.

[kamov]

I have even tested by not adding guard_name in user model, with HasRoles trait, and there is not any error generated... so I am even more confused now ..

[drbyte]

v2 guard lookup currently looks to the model's guard_name property, with fallbacks down to finally the first available guard in your config array of guards (not the one listed as "default"). Null doesn't disable this lookup.
So, wherever you don't specify a guard when doing a permission check, it does the lookup according to that pattern I just described.

[Daniyal-Javani]

v2 guard lookup currently looks to the model's guard_name property, with fallbacks down to finally the first available guard in your config array of guards (not the one listed as "default"). Null doesn't disable this lookup.
So, wherever you don't specify a guard when doing a permission check, it does the lookup according to that pattern I just described.

Shouldn't it check the guard of logged in user?
like this

function activeGuard()
{
    foreach (array_keys(config('auth.guards')) as $guard) {

        if (auth()->guard($guard)->check()) return $guard;
    }
    return null;
}

How can I check based on the guard of user?