Support Path Identification

[rrpadilla]

Description

This great package ONLY support domain/subdomain identification.

Path identification would be identifying the tenant based on a part of the URL path, specifically the first section after the domain. An example of this would be

https://myawesome.app/app/tenant-slug

where "tenant-slug" is the tenant identifier.

Even we can use the domain too in case you want to reuse the domains table:

https://myawesome.app/app/tenant1.com

in this case "tenant1.com" is the tenant identifier.

Basically we should be able to use: "slug", "uuid" or "domain".

Why this should be added

• You do not have to deal with domains/subdomains configuration and your customers do not have to change DNS records.
• HTTPS supported for every tenant out of the box. With domains/subdomains you and your customers have to configure and maintain multiple certificates.
• Vapor Support. See Ensure Laravel Vapor is supported #74. Vapor does not support multiple second level domains.
• Really easy to test locally because you do not have to update the .hosts file.

Thanks!

[rrpadilla]

@stancl will be great if domain, subdomain and path identification can be supported at the same time. Then your SaaS can have:

• basic plan (Only path identification. NO custom domain supported.)
• premium plan (custom domain supported)
  Thanks!

[stancl]

I think this is a good consideration given the things I've been changing about tenant identification lately.

The ideal scenario would be that both domain-based identification and path-based identification would work.

I think with 2.0.1, you should be able to use a route group with the InitializeTenancy middleware for this.

However, in 2.1.0 I'm changing the InitializeTenancy middleware to be executed globally. It initializes tenancy if the current domain is not a central domain, and then when the route middleware is being executed, the PreventAccessFromTenantDomains middleware checks that central routes can't be visited on tenant domains, and vice versa.

The reason I'm changing this is that it's the only way to initialize tenancy before running controller constructors.

So you do need some concept of a tenant domain.

However, I think you should be able to use a single subdomain not listed in the exempt_domains config, such as app.yoursaas.com and then inside you'd initialize tenancy manually inside a route group. Though the global middleware initializes tenancy using a domain, hmm. I think I'll make the middleware swappable.

Anyway. I think that using subdomains, such as tenant1.yoursaas.com is good enough functionality. But, if possible, I'd want a solution that lets you use path-based identification too.

[stancl]

From a code design perspective, I'd like the package to be able to do this. From a practical perspective, all the use cases you listed can be solved by using {tenant}.yourapp.com.

[rodruiz]

Hi @stancl,
actually using subdomains without sharing session is even better and more secure.
With path identification should exist another middleware/authorization layer to protected access to the tenant path.

Thanks.

[stancl]

Yeah, it's really the best solution. The app will just work, certificate and DNS management remains the same, and Vapor does support multiple third level domains.

[stancl]

Closing in favor of #207