tenancy / multi-tenant

Run multiple websites using the same Laravel installation while keeping tenant specific data separated for fully independent multi-domain setups, previously github.com/hyn/multi-tenant
https://tenancy.dev
MIT License
2.56k stars 394 forks source link

Configurable HostnameIdentification job #931

Closed isecchin closed 4 years ago

isecchin commented 4 years ago

Description of your feature

Hi guys, I stumbled upon a feature request for my system yesterday and was thinking about a possible solution for it.

The problem is that I'd like to provide some public facing routes (that doesn't require authentication) for some of my tenants, but without exposing their URLs (I know people can still find out the URLs, but this way it's not as trivial as getting it from the navigation bar).

What I thought about doing was creating a dummy public.example.com hostname and sending some information (maybe the uuid) of the tenant as a parameter for the routes to be able to retrieve the correct tenant for this routes, or even use a completely different domain, like public.com, without attaching this domain to any actual hostname, so it will never fall to the secured application.

Right now I had some trouble trying to implement it in an easy way, without having to register new hostnames in the database and stuff, and still using the early-identification, the abort-without-identified-hostname and even the auto-identification configuration (as a fallback).

So my idea would be to simply make the HostnameIdentification job configurable, this way we could just extend it, try to get this public hostname or fallback to the tenancy's default identification process.

I don't think this would be a breaking change (specially if we use the current Job as the default one in the config), and could potentially make things a lot easier to implement manual hostname identification.

I'm completely lost if this is the best way to do what I need (maybe not), so if someone already had a similar problem and could share some thoughts, it would be great !


Proposed behavior

Being able to configure the HostnameIdentification job on the tenancy.php config.

This way, we just need to change: https://github.com/tenancy/multi-tenant/blob/963987bd90266b3f7d2d0e9af35a97d0d346f8be/src/Environment.php#L80

To something like:

$job = config('tenancy.jobs.hostname_identification');
$hostname = $this->dispatch(new $job());

Add the job to the tenant.php config:

'jobs' => [
    'hostname_identification' => \Hyn\Tenancy\Jobs\HostnameIdentification::class,
],

And we could then extend the job and use the default one as a fallback:

use Hyn\Tenancy\Jobs\HostnameIdentification as Job;

class HostnameIdentification extends Job
{
    /**
     * @param Request $request
     * @param HostnameRepository $hostnameRepository
     * @return Hostname|null
     */
    public function handle(Request $request, HostnameRepository $hostnameRepository)
    {
        // Logic to retrieve tenant goes here
        if () {
            return $hostname;
        }

        return parent::handle($request, $hostnameRepository);
    }
}

Current behavior

Currently it's not possible to configure/extend the job.


Information

fletch3555 commented 4 years ago

I don't quite understand what problem you're trying to solve...