Laravel 5.3 - Structuring controllers into Modules with separate sessions, authorisation requirements and standard functionality/services

We have built and continue to develop a web application in php, based on an in-house web-framework. Our web-framework was written before Ruby on rails was anywhere and certainly before anything similar was available in php (ie before Symfony). We have often reviewed using a more standard framework, but until recently there was too much functionality missing for what we were doing (particularly queues, jobs etc).

We believe that now frameworks like laravel 5+ cover what our framework does and more. It's more modern, more expressive, etc, so we are considering rewriting our application using laravel 5, because it will be easier to obtain programming resources etc. We have been researching laravel, but have little experience with it.

This question is about how to approach the general architecture using laravel Controllers, Providers and Middleware, Auth, Routing etc. Our application has about 250 Controllers and our model has about 110 SQL tables using Propel ORM (which we would obviously migrate to Eloquent). The 250 Controllers are structured into what we call "modules", each of which is targeted at a different subset of the userbase. Our application serves "organisations" who have "members" some of whom are "administrators" for an organisation. This is an outline of the "module" structure:

Modules

pub : Publicly viewable pages, no login or session, trivial really

org : Publicly viewable pages for each organisation every (!) page has the context of an organisation and all the routes have a "slug" for the org in them

sec : extends "org" module, but now the member has logged in, so every page/route has context of member AND org. Facilitates transactions between the member and the organisation.

orgadm : extends "org" module, but an organisation administrator is logged in. they can access slightly modified versions of the "org" pages and completely separate "orgadm" routes/pages for administering all the data of the organisation.

mem : there is NO org context here (ie no org slug), but a member has logged in and can see all of the organisations to which they belong, manage their own personal data, etc...

adm : Superadmins (internal staff) who can view/manage all orgs and all members

sysadm : Only for sysadmins who are monitoring jobs/queues etc...

restapi : self explanatory

Sessions pub : requires no login or session

org, sec, orgadm, mem : share a session / cookie

adm and sysadm : share a different session / cookie. The cookie has "path" set, all routes have that prefix, and the user db is completely separate (and quite small).

Common "services" and functionality

org,sec,orgadm : extend the same base and offer certain services to all of the controllers in those modules.

Initial ideas for Laravel architecture & specific questions

With our, currently reasonably naive, understanding of laravel 5.3, the simplest ideas to address each of the above seems to be:

• Write some abstract Controller classes which represent the "modules". Concrete Controlers for each "module" extend the appropriate abstract class. The abstract class provides the common functionality for the module either by containing the methods itself or by acting as a conduit to some laravel "Provider" which we write for each of our "modules". If this is sane in laravel terms, we think it could work for org,sec,mem,orgadm (the core of the app)>

• To differentiate between our org, sec and orgadm modules, we have our own concept of "roles in an organisation". We are not sure this fits well with laravel authorisation, but maybe that's not insurmountable?

• For adm and sysadm we have no idea how to implement the "seperate session/cookie" aspect. We think this is important from a security perspective. Our only thought in a laravel world is to use subdomains and almost separate apps accessing the same backend DB instead?

• restapi: similar to adm etc...really should this be done as an entirely separate app as well?

This stackoverflow question seems to partially address some of the above aspects (ie division into modules) from a routing and controller direcetory sytructure perpective, but nothing about the auth/session stuff.

Sorry for all the detail, hope the questions are clear.

via Chebli Mohamed