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
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.
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, likepublic.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
, theabort-without-identified-hostname
and even theauto-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:
Add the job to the
tenant.php
config:And we could then extend the job and use the default one as a fallback:
Current behavior
Currently it's not possible to configure/extend the job.
Information