I have setup an API in Laravel using Passport for authentication and spatie/laravel-permission to add permission functionality. I also have a calling application, again written in Laravel. I can authenticate from the calling app to the api but how do i ensure that the calling app knows the permissions available? What should the user/roles/permissions tables look like at the api and in the calling app?
Essentially i would like to use code like: $user->can('do something') in both applications.
My understanding of the Spatie package is that it allows you to make such code calls as $user->can('do something'), and reading the Github page it looks like it creates tables default named "role" and "permission" when you run the Migration after installing the package. In other words it's a matter of configuring the models and database connections in both of your apps correctly, specifically the User Model and the Permission table for both apps.
To clarify, I think you are asking these questions:
how can a second app know what permissions are available,
how would you be able to use something like "$user->can('do something')" in BOTH applications, touching the exact same data.
Answers:
If the "permission" and "role" tables already exist, then if your API doesn't have some endpoint to ask for the roles or permissions already available, you'd define a new one. For instance, some API call that asks the Permission table "getPermissions" or something and that your second application can call -- it either has to ask the database itself (via the API), or it has to get that from the second application. Which depends on how your two applications interact with each other
you would have to make sure to configure the second application so that the "User" model refers to the same table as the table the first application uses for the User model. Essentially, the model is being used as an interface to the table, so if both applications have a defined User model that references the same table and both are configured to connect to the same database that table is in, Laravel's user model will "just know" the data in question (this is the basis of Laravel's Eloquent for Models).
Additionally, for what it's worth, I haven't used the spatie/laravel-permission package, but in relation to question #1 I did find a function in the docs that might also be used to grab currently made permissions in list form from a "permission table":
Permission Model, getPermissions
And for reference, about Laravel's Eloquent and Models (which may be something you already know, but I'll leave this link anyway):
Laravel Eloquent ORM
Related
I am using django-allauth and dj-rest-auth in my django-rest project to register users and allow them to sign in to my react-native app. The problem I am having is that when the user is registered, it creates the particular user in a social accounts table. However, I want to also create a user profile for each member who registers via Facebook and store additional data (name, email, picture). I have had a look at docs, blogs, stack-overflow but just can't seem to figure out how I can do this.
So far, I have a social_login app which manages the login and has a view which has the following:
from allauth.socialaccount.providers.facebook.views import FacebookOAuth2Adapter
from dj_rest_auth.registration.views import SocialLoginView
class FacebookLogin(SocialLoginView):
adapter_class = FacebookOAuth2Adapter
How can I edit the social accounts model? and how can I create a user profile in my users app once a user has registered using Facebook?
Update:
I have realised that I can only have one user auth table in Django which manages user, regardless of whether they are customers or staff. I have now migrated to using a custom user model using the AbstractUser from Django. I could potentially create another table for user profiles which could then hold additional details or extend the model I have now. I will extend the User model I have created as I think created an extra model would be overkill for my current needs.
This blog post helped me migrate to using a custom user model mid-project.
I also realised that I am able to make use of allauth signals (user_signed_up in particular for my case) in order to trigger a function. I'm fairly new to Python/Django so didn't even know what a signal was till about 30 mins ago. It's fair to say you learn something new everyday :)
what I want to create is Laravel 5.2 Admin and there are around 200 users who will use it with different permissions, so you can say 200 roles with different permissions.
I was planning to eliminate the role part from the picture and create some slug based mechanism, slugs will be related to controller public functions in short routes.
In Admin panel superuser will be able to assign permissions to user on controller functions with slugs.
Is this possible with any existing laravel package currently? If not then what will be the optimal solution you guys propose.
I always use Spatie Package, it is very flexible. You can manage role & permissions or only permissions. It is full of functions that make it easy. Check the documentation.
spatie-laravel-permission
We have an API which connects to our own first party applications. Our API is sending out notifications based on user actions or if there is an update to the application etc.
Our API is modular structured.
Example
Our user model in API is located in App\Modules\Accounts\Models\User. Each month we send an invoice database notification to user from our API. In database it adds the notification and the notifiable_type is App\Modules\Accounts\Models\User.
But in our user application the user model is located in App\Modules\User which results user having 0 notifications.
Question
I know I can move the user model to exactly the same path in the user application but it seems somewhat wrong. Is there a way to tell the user model in our user application where to receive database notification on? Something like:
public function(){
return $this->receivesNotificationsFrom('App\Modules\Accounts\Models\User');
}
I would solve this in api as like this (suggesting, i would also use your namespace for users like you did, what i would never do, but lets suggest it). There are several ways to test, what is the best solution for you.
I would:
In your consuming app, you create a new model App\Modules\Accounts\Models\User that just extends your existing User class. I would test, if i can get to goal with this approach.
You create an artisan command to just rename the classes in your notification table and let this run by laravel's scheduler, so in your notifications table are the correct namespaces for your app.
This all "feels" wrong and i would never break with the defaults of App\User, because you run into traps like this and end up with "messy" solutions like 1 or 2.
Sry, i have no better ideas now, but maybe, it gives you some little inspirations 😉
I am building an app and will need multi auth to works well. First, users that will log as employees using table users with email and password. I´m using Voyager as backend and using roles and permissions. So far, so good. Now I have another kind of user: they are registered on an ERP and I reach then via WS using CPF (like the social-secure number) and password stored in ERP. Then I get then and record at a table all the data I need. It is working well as good. Well, was working. For those users, I used the API route, just not to make a mess on my web routes file. Yesterday I ran PHP artisan make:auth and that´s when things start to get crazy.
Every axios call now returns me an 'unauthorized' message cause, obviously, they´re not authenticated.
What would be better?
Refactory Users login to use CPF instead of email and give a new role for those others API guys and make then pass trough web.php file like everybody?
Use a multiauth package?
Or anything else?
Please, help!
To me, a user is a user. It seems to be a common thing that if an application has more than one “type” of user, that developers instantly start creating multiple Eloquent models, then guards, then controllers, then views, and so on; and then find themselves in a mess when they need a route that can be accessed by more than one type of user.
Instead, elevate “type” to its own model and add it as a relation to your User model. If a user can only be of one type, then make it a one-to-many relation. If a user can have many roles, then make it a belongs-to-many relation. You then use authorization to determine whether a user can access a route based on the role(s) they have.
I plan to develop a system that has three user types (admin, business, personal). I want to have each user types information stored in a separate table for easy access and to reduce the number of blank fields (if they were all in one table).
Having looked at multiple Multi-auth packages available for Laravel, they all appear to be insisting on an approach with URLs like the following:
/admin/login
/business/login
/personal/login
Ideally, I would like to take an approach where the standard Laravel Auth /login can be used meaning that all users log in from the same page.
My knowledge of Laravel is limited so all and any help is appreciated.
The usual approach is to have one users table which has the ID/email/username (as primary key), login credentials and user types for all the users which will be logging into the system. The information however can be stored in separate tables for each type, referencing the foreign key.
After authenticating the user, then you can decide what to do with the user based on the user type.
If you store login credentials in multiple tables, that's data redundancy. Unless you want the same email/username to have more than one user type, but then during login, the user has to decide which user type they want to log into (maybe by selecting a dropdown option).
Update: about user roles
If you need to simply redirect users after logging in, use $redirectTo. Or if you need to decide what to do with the users depending on the roles after logging, you can make use of authenticated() method (add this method if it's not already there, it will overwrite the AuthenticatesUsers trait) inside your AuthController/LoginController.
Throughout your application, I'd suggest assigning middleware to route groups to restrict routes based on user roles. And yes, in your views and controllers you can use something like if(Auth::user()->hasRole('business')) when needed, but first you'll need to create the hasRole() method in your User model. If you feel it's getting complicated, you may try packages like laravel-permission and Entrust. I haven't tried them though :)