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.
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 a web app which I need to duplicate for multiple clients.
Each client will have his own server space and a database.
Each database will have one user table per client and they have independent data from each others.
Clients could access to their site via sub-domain URLs.
One client's URL may look like this ex: www.abcgroup.example.com (client: abcgroup)
I want to have one centralized login page at www.example.com/login.
Once a client login, he will be redirected to abcgroup.example.com automatically, without having to type his own sub-domain URL.
ex:This site managed to do it https://tictail.com/
Problem is that I have multiple databases with multiple user tables. So how can I authenticate users globally from one login page?
I'm not sure whether I have to check against all the user tables in client databases.
Do I need to read from all the user tables? (I'm using Codeigniter 2)
Thanks!
2 ways to do this:
Have a central DB that has all the users. This makes sure all the users are unique. Having multiple DBs, you may run into duplicate users.
Making the user select or type in the subdomain in the login page. Some web apps do this.
I'm building a site that has two areas: the main site, and an admin area.
The main site has to have Facebook login functionality (I'm looking at using Sammy K's Laravel Facebook SDK) and the admin area is just going to have a database-based login; basically the Laravel login system.
I'm wondering how to approach this, and whether anyone's done this before. Some design considerations:
Should I have two separate user tables?
Should I use two route filters, one for each auth type?
If I only have one user table, should I use different groups (somehow - I'm not sure they'll built in?) or some indicator to let the system know whether it's a database-based, user/password login, or just a Facebook login?
since you are using facebook SDK,
you don't need a user table to begin with in most cases/projects.
if you indeed want to use two different authentication, then yes, use one for each auth type.
assign different routes for each of the case. don't need to bring all those different entities together and make a sandwich.
I am trying to create a login system thats generic so that it can be adapted for use in various apps. I decided that 2 main "parts" of the system will be User Meta Data & Roles/Resources/ACL.
1. Metadata
I thought of keeping most data like what meta data are available for users in the database, so that admins can manage them using some GUI.
Problem is how can I then configue how I want inputs to render (textbox, checkbox, radios etc.). Then another problem is validation, filters.
2. ACL
I think for simple ACL it will work fine. But suppose I want say users to be able to modify posts they own. In Zend_ACL that is accomplished with Assertions. I thought that will make a "simple" login system overlly complex? Also it will be hard to build I suppose?
Currently I have my database like
Logging in users: I recommend using a separate controller (call it Auth for instance) that has loginAction and logoutAction. Zend_Auth (Zend_Auth using database) will check the database for the right credentials. Once the user is verified, you will save it in the global accessible place(the Zend_Auth class has methods to do this). This is also a good moment to query which roles the user has and store them.
Metadata part of your application: I'm not sure what the question is exactly but I assume you want to store dynamic information about user and have a GUI for admins to manage this. Why you would render different types of controls? Validating the information can be done by defining a lot of the most common metadata (like Twitter) and create rules for them. In the save action for the metadata you would validate using these rules.
ACL: Resources rarely change, you are better off putting them in a configuration file (for speed). You should give a lot thought to resources: what are they exactly to you? Controllers? Modules? Create a plugin that will preDispatch every request checking the role of the logged in user against the requested resource. E.g.:
$action = $request->getActionName();
$controller = $request->getControllerName();
// role, resource, privilage
if (!$acl->isAllowed($user->role, $controller, $action) {
//go to access denied page!
}
Now that Zend_ACL is used for the global access rules, you are better off checking for specific access inside the action itself (like if ($loggedInUser == $article->author) {//edit the article};).
Also don't forget Zend_ACL can be integrated with Zend_Navigation to hide menu items users are not allowed to use (and more).
I am creating an web application and I at the point that i am starting to make backend choices. Now there are a lot of ways to go with this, so I am looking for some good points and back practices.
Some of the question i have involve:
Should i make a seperate table in the db for admin users
Should i extend make some classes to load the admin data and the normal data, or make seperate classes for the admin section
Where can i get some information on making different types of users
Just some best practices for a backend
My application is written in PHP with an MySQL database.
Keeping a separate table for admin users is nice, but only if those admin users aren't "regular" users as well - otherwise you'll step on your own toes trying to keep usernames/IDs unique but somewhat connected.
A couple things to consider:
Apache authentication (or Windows accounts on IIS) for admin users. Separate system entirely, but allows for overlap - a regular user can be a regular user, but they can't access any admin functionality until they authenticate through the browser. Works fine if you only have a couple specific kinds of user role (e.g. member & administrator only).
All users in one table, but with roles and permissions separate. This is the most flexible because you can get as granular as you need. For example, any user can "post comments," while an admin can "delete comments" and "ban users," but a moderator can only "suspend comments" and "mute users." As you add new features, it's simply a matter of implementing some new permissions & assigning them to the roles. Drupal's access control does this really well, worth a close look.
A good way to do it is to add a new field in the users table for 'rank' in order to differentiate between regular users and staff members, and possibly between the different staff member levels such as moderator, admin, etc. if you need it. Because an administrator should be able to perform all functions that a user can. Use
class Admin extends User { }
if you want to add additional functionality specific to staff members.
As for backend functions, that depends on how your site is set up. If you're using a framework, you can just add new functions to existing controllers and restrict access only to users with a certain rank.
For example, you might have a controller for ForumPost objects, but calling the ForumPost delete() function would require the user to be a forum moderator.
If you're not using a framework, you'll probably have to make your own pages for each backend function you need.