Open iambateman opened 2 months ago
I think that if the user app env is Local we allow access to anyone from the /analytics
route. This way when the user is developing locally they don't have to worry about authorization. A lot of Laravel packages like Horizon and Pulse do things this way.
I think the easiest way would be to tell users to add it to a service provider where they can specify a Gate that would allow specific emails like this:
public function boot(): void
{
Gate::define('viewSignal', function (User $user) {
// List of emails
$emailAddresses = [
'alloweduser@example.com',
'anotheruser@example.com',
];
// Allow access if their email is in the email list above. Easy peezy!
return in_array($user->email, $emailAddresses);
});
}
Or we can tell them that they can add it in a more conditional way like this:
public function boot(): void
{
Gate::define('viewSignal', function (User $user) {
return $user->isAdmin();
});
}
Local-is-open makes sense to me!
Service provider I actually ran into this this morning on Prodigy – my client asked for access to his backend and I had to push a code change to add him to the service provider.
I think it's fine to start there, but eventually I hope to manage users within Signal itself. That way a marketer doesn't have to call their developer to add the SEO guy to the app, ya know?
ooh last thing on that...
I can see a lot of apps where the devs don't necessarily want their marketing folks to be admins in the app itself. 😂
@tnylea What do you think about how to auth users within
/analytics
?Options I see:
Adding them in the service provider has been frustrating for Prodigy because it's just hard to remember, and code changes just to add people is annoying.
Since we have our own db, we could just roll a Laravel auth into the package.