I've implemented multiple authentication in my Laravel application and I have two different tables to accomplish this task (users and clients).
Everything works fine, the the only issue I've met is related to social authentication. I've followed all the configuration about Socialite-plugin but I don't know how to set up the redirect URL depending on wich type of user (users or clients) is trying to log in.
Any suggestions?
How you check if user is user or client?
You can add extra parameter to redirect route
Route::get('auth/{type}/{provider}', 'SocialAuthController#redirect')
(where {type} is user type)
Related
I have a Laravel user database (> 14k customers) and would like to authenticate and authorize all users accross multiple websites of our company (2-5 Laravel and .NET webs) from a single OAUTH server.
https://laravel.com/docs/9.x/passport seems to document only workflow when "OAUTH clients" are added per user (witch nice and also a requirement), but I want to have global "clients" available for all users. I dont want my users to be able to remove their access to other websites of our company and even more be required to add it one by one in order to use it.
Workflow:
User comes to one of company sites (1.company.com, 2.company.com, 3.company.com...) and is redirected to server oauth.company.com and after successful login redirected to the original target website.
User can add aditional clients, but are not required to add 1.company.com or other sites of our network.
Is that even possible with passport?
I have the following setup for my website:
UI - using React
Backend REST API - using PHP
For authentication, I used AWS Amplify. So I host the UI in Amplify console and setup the backend environment for the authentication. In my UI, I have 2 pages:
Home page - "/"
Main page - "/main"
I wrapped the Main component in withAuthenticator from #aws-amplify/ui-react. With this, when i go to "/main" and the user has not signed in, it will show the default SignIn/SignUp from amplify.
My questions are these:
There are some parts on the Main page where I need to hide for non-admin users, say an "Admin" button that is only available for admin users. In Amplify Studio, there is "User Management" where you can create users. As I understand, it uses AWS Cognito for the user pool. But how should I configure a user to be an admin?
Since I am wrapping the UI's main page inside Amplify's authenticator, I can be sure that only authenticated users can access that page and send requests to the backend. To make sure that I am only showing buttons that are for admin users, I am thinking of creating an endpoint called "/profile" that will be called once my Main component loads and it will return an attribute telling me if the user is an admin or not. But how do I check if the user is an admin from inside PHP API?
The logged in user can update his profile like update his name, location, etc. For this, I will create a user_profile table in MySQL to contain these other user attributes. When the user first signup and confirm using Amplify and he's routed to the "/main" page, I'll call the "/profile" endpoint and check first if the user exists in the user_profile table? If not, I'll add that user so he can update his profile later? Is this the right approach?
Since my PHP REST APIs can be called even through say Postman, I also need to check in the backend if the request has the amplify token and check with Cognito if this is a valid token. So for all endpoints, I need to check if the token is valid. Is that correct approach and how to do that?
I am thinking of deploying my PHP REST API on an EC2 instance. I believe since they are all inside the AWS environment, I won't be having issues calling the endpoints from my UI. Is this the right approach?
The same of my MySQL db, I'll deploy to AWS RDS. I hope this is correct.
I hope for your kind guidance on my doubts. Thank you.
So they are a lot of questions for 1 post. It would be better to ask each question in a different post as right now more than technical issue it looks like opinionated architectural discussion.
Reach application can be build and exported into static website. Then all the integrations can be managed by CSR (Client Side Requests). This is a cost efficient and performant way to host react websites. You can host the site on S3+Cloudfront and don't have to manage any servers
For your APIs use API Gateway + AWS Lambda (Your PHP code). You can use token based authentication for your APIs and yes have to check every request if the token is valid.
To check if a user is admin or any other role you can create "groups" in AWS Cognito. Reference to create groups is below
Now what type of user can perform what type of role in your application has to be implemented in your application itself. Cognito can't help you with that part
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-user-groups.html
Note: There is no code to show or prove it, we just need a methodology to solve the problem before implementing the code to our code base.
We have more than one user for our fashion web (laravel app)
Guest (does not matter to this issue)
User (Fashion lovers/Customers/Clients)
Tailors (Fashion designers new/existing accounts in the platform)
The users(customers) can login and register to their application without no problem but our problem is how can we filter the two users(customers/tailors) such that when a user (tailor) logins to www.app.dev/tailor#dashboard (without access) it redirects to (www.app.dev/login) and when the user is a tailor it takes the user to tailors login page instead the user (customers) login, Do you understand me??
check for following stackoverflow questions
Can anyone explain Laravel 5.2 Multi Auth with example
How to use multi Auth in laravel 5.2
Multiple auth user types in Laravel 5
Can the same user have multiple sessions to the same app in the same browser as long as another field is added to the authentication process (email, password and website_id)?
I'm building a PHP app that allows the creation of multiple onepage websites. Each website should serve as standalone sites, with different content but they all have the same backend. Each website has a separate set of users/customers. A user can signup on any website but the websites don't necessarily share a user base. This means that a user can go to site1.domain.com and register, and then would have to register again if they wish to visit site2.domain.com.
They will probably register using the same email address, so my user table allows for duplicate email addresses as long as they're not in the same website.
This is sort of a very simple CMS. Kinda like what magento does with multiple websites running under the same instance. They also allow each separate site to have they're own customer base.
I plan to use Laravel for this project. My current approach is this:
Modify the provided user authentication functionality to add the site_id field. This means the user can register with the same email address in multiple sites, and can also log in to all those sites separetly. If they're logged in to site1 and visit site2, they have to log in again and have two separate sessions for what would appear to them as two different apps, but is just the one.
In theory this seems possible to me. A cookie is created for each separate subdomain once they login, which wouldn't work on a different subdomain. I feel like I'm missing something big though, I've never done something similar to this and always relied on Laravel to handle all the session stuff for me. Is this possible without some heavy hacking to the Laravel codebase?
UPDATE
These are my constraints:
The desired affect is that each website appears to be a separate application alltogether and not related at all to the others but all tied to the same backend and with the same routing/views.
userbase and user session cannot be shared between sites. I can make it so a user registers once and can login to every site, but I don't want that. A user should be able to visit every website separately.
every website will have a different subdomain, or in same cases, a different domain alltogether.
PHP sessions are tied to the domain name, so they will automatically have different sessions for each of your apps. You can use route-model binding with a custom resolution to determine the app based on the domain.
routes.php
Route::group(array('domain' => '{site}.com'), function() {
//routes go here
});
RouteServiceProvider (in boot method)
$router->bind('site', function ($value) {
return App\Site::where('custom_domain', $value)->first();
});
This is based on the assumption that you have a Site model with a field in the database called custom_domain. All of the routes available inside the group will have access to the Site using dependency injection. You can adjust the model and field based on your app needs.
You can use the model to customize the login-page for each app, and the apps will have independent sessions for each one.
I've also heard great things about the Landlord package. You use a middleware to define which Site the user is, based on the url. Once that is set, all eloquent queries will be automatically scoped based on the site_id in the database. So User::all() would only return users for the current site.
I am developing an application using Laravel 4, where I need to have 2 authentication types.
Type 1: Users - which are administators / back-office workers of the system.
Type 2: Customers - which are the visitors of the website who can do certain things (like purchase services) if they are authenticated.
The Type 1 Users are authenticated using username/password, so that fits nicely within the Laravel authentication model.
The Type 2 Customers will be authenticated either using OAuth style (with Google / Facebook) or manual authentication if the customer prefers. I do not want to mix the two together, so if you are authenticated as a customer I don't want the authentication filter to think you can access the admin pages, and vice-versa.
The two types will have their own tables (Users and Customers respectively). Is there a way to have a different Auth model running concurrently in some way? Or do I have to write my own thing for customers? What is the recommended approach in this scenario?
If I understand your question correctly this should set you on the right path.
You can simply set an account_level indicator in each table and wrap your admin routes in a filter that checks that the user's account_level is correct. For example:
in routes.php
Route::group(array('before' => 'admin_only'), function() {
Route::get('my-admin-route', 'AdminController#adminAction');
});
in filters.php
Route::filter('admin_only', function() {
if (!Auth::check() || Auth::user()->account_level !== Config::get('constants.ADMIN_ACCOUNT_LEVEL') {
return App::abort(404);
}
});
In order to log a user in that does not have a username and password in your system you would need to handle the OAuth connection separately and once you have a valid user you may use the Auth::login($user) method to get the user back into your usual application flow.
http://laravel.com/docs/4.2/security#manually