My app needs to support two types of users:
regular users , these are those who are subscribers (restaurants
that use my app for managing their business). For these users, I
have the out of box authentication (Laravel 5.1) set up. email and
password are the fields I authenticate on. I maintain information
about such users in my users table.
guests, these are people who
visit the restaurants above, register to earn loyalty points, check
their score, leave feedback, etc. I maintain information about such
users in my guests table. Authentication, in this case, is simple.
I just use a mobile_number to authenticate them into the app.
I get that I can implement guest's authentication in a subdomain of my app, with different Controllers and Views.
What I don't get is, how can I use the eloquent database driver with the two distinct models? I see that we specify the model eloquent would be using through config.auth.model. So, I'm assuming that we can only have one single model implementing authentication.
Is, what I trying to achieve, possible without implementing a custom driver?
Short answer: No.
You need a custom driver for this. But that shouldn't be too hard to implement, as you can easily get inspiration from/or extend the current EloquentUserProvider. You can also check out the answer to this other question:
Custom user authentication base on the response of an API call
The context is different than yours, but it may help getting a better grasp on the implementation approach (that is if you haven't done this before).
Related
I am building a Laravel webapp, where I need to implement a custom registration process. Now I am not sure, whether I can/should use the built-in Authentication features from Laravel or not.
I have three types of users:
Admin users: My colleagues in my company who talk to clients, onboard them, etc.
Clients: Users who create certain tasks, that need to be done. They could more or less use a "standard registration" process
Service Providers: Users who fulfill tasks for clients. They need to be onboarded by our company. So our admin users would create their user profile and send them an invitation link.
Especially the Service Providers are giving me a headache. Is this kind of custom registration flow possible in Laravel or do I have to build my own custom athentication to accomplish this?
Thank you for posting your question. I have implemented Laravel Authentication with custom features before, I would recommend you to take the following steps:
Install Laravel Authentication.
Update users table with a column name type that will distinguish between users.
Create middleware for each user. Middleware helps you which user can access or perform which tasks.
If you have different elements for each user then you can also implement policies or gates to show specific elements on your blade template according to user type.
I would not recommend creating custom Authentication for this scenario, as you have to implement proper session handling throttling, forgot password, verify the process along with emails and notifications. which is built-in by default in Laravel.
If you want to edit the register and login function you can do that. ;)
I am new to laravel and creating a REST API. The client of the API will be mobile app only. There is no front end view to be shown in browser. I have created the routes and the controllers to handle API requests. Furthermore I deleted the Users table (created by laravel) because I do not need an Web interface etc.
I just want simple token based authentication at this stage ( I am aware there is passport authentication) but I can not even understand that at this stage.
There is only one table in the project.
Candidates
(id (PK), name, phone, details)
mobile app users are candidates also, should I create a token column in this table ? and manually create token at the time of register API and return it back as response ?
Please any simple guide or directions will help, I have search quite a bit online and there seems to be quite a lot many topics that show up such as guards, providers, passport which I am struggling to get.
Thanks,
Elliot.
First of all, you didn’t need to delete the users table. You can use it for api auth too. You just need to create a seperate token table.
However, if you want to implementit manually you need to do a lot of things manually.
This is a huge thing to impelement manually and it's not possible to describe it in a single answer. I will try my best to explain it as simply as I can.
You have to create a authentication system yourself that is for login. Define a middleware to check the authorization of the token sent from client to check the validity of every request (this is the guard part).
Also keep track of the token expiry time. Refreshing the token after each expiry needs to be done too (this is the provider part).
Now there are a lot things inside. Like keeping track of the device the request is coming from, providing different tokens for differenet devices for a single user etc.
If you are into learning how everything works then you can try to build one yourself. But if you plan on deploying it to a professional website, I would suggest try to get accustomed with passport. Reinventing the wheel is really not necessary. I hope it gives you a basic idea. If you have any more questions feel free to comment.
Okay so I know there are a ton of tutorials out there talking about changing the authentication to your liking, but I couldn't find one for my specific case. So here it goes:
In one of my projects I've been using the standard authentication system that comes with Laravel. I have a user model, and each user has an email and a password. They also have roles and permissions and everything works as expected.
I also have a client model. There are projects and each project belongs to a client. Now there is a new requirement for the app, where clients should be able to login and see all of their projects.
Clients should login with a username (not email) and a password.
My question is: What steps are necessary to completely get this going. All I can find online are some pieces of the puzzle, but unfortunately I'm not able to put this together on my own. I know it involves creating a user provider, but that is only part of it. How do I hook up routes/controllers for this, how do I use the custom user provider, how can I use the Auth facade in addition to the standard "user" authentication (I will need to use both side by side)?
If someone knows of a comprehensive tutorial I will be happy to read that and apologize for this question ;-) Otherwise I will be very thankful for a little checklist of all the things I have to consider.
PS: There a many reasons why I can't just use my user model with a special role or something like that. I need to use the client model for authentication.
I found this tutorial which contains the gist of what you're looking for. The basics come down to something along these lines:
Create a new Authenticatable model
Adjust auth.php with new guards and providers
Adjust routing to take both models in account
I'm not sure how the Auth facades plays its role in this, but it might require some additional configuration.
I have the following setup - the Spring SAAS REST service, which allows different companies to manage different events. And there is a rest client (a mobile app) also, shipped separately for each company.
I want to use keycloak for security stuff, and I have a question of how to separate one company from another.
I need companyA to not be able to access companyB event, and also need different roles within the company - some can create events, some can only read it.
First I thought each company will have own realm created in keycloak, but I learned that realm actually specified in the spring boot REST service parameters like
keycloak.realm=demo-realm
Which means it is only one realm per REST application. And I don't want to configure REST service instance per client. I only want one REST rule them all.
Am I trying to use something which really doesn't fit my use case?
Will it be right way to have a keycloack Group configured for each company, and make a logic in such a way that users of one group won't have access to what is created by other group. But then it actually feels wrong, since as I understand group are supposed to be used in a different way - to have admin group and user group, etc, segregating users "vertically" by "privileges", and not "horizontally".
Can you please suggest a right approach for this problem?
I would implement a custom protocol mapper which loads extra user permissions for your application and stores them in a token. This way, you use a single realm and if there are more companies in the future it scales well. Here you've got an example of how to implement it.
Basically, the otherClaims field of the access token is a JSON field that allows a map of properties to be set. You could add a field here such as:
userAccessibleCompanyIds: [1,3,4]
How to load the company ids for the concrete user? You can access your application database from the mapper or get them using the REST API.
Then in your application you need to have a control of what the user accesses. What I do is decode the token and see if the user request suits. If not, return a 403 response.
I'm designing an app that counts on accessing multiple API's that need the certain users credentials which are provided when a user allows access via OAuth. I'm new to designing programs like this and I'm trying to wrap my head around the easiest way to do this. Here is what I was thinking:
During the Oauth process I specify the callback url (lets call it A)
Create a POST route for url A that points to a function in the user controller
That function then parses the JSON data with the API Key+Secret, hashes the data, and stores it in a column of the user table.
Would this be the best way to go about this?
One thing I'll say is don't tie these directly to your users. Sometimes users may want to authorize multiple accounts, and sometimes multiple users may authorize the same account. Since you can only have one active refresh token per oauth account, these creds should be kept in a separate table and then linked with a many-to-many for flexibility