gecche / laravel-multidomain

A Laravel extension for using a laravel application on a multi domain setting
MIT License
838 stars 105 forks source link

Issue with ngnix wildcard sub domain #41

Closed satheesh365 closed 3 years ago

satheesh365 commented 3 years ago

First of all thanks for the nice package.

When I try to use wildcard domain setup in ngnix like below

server_name ~^(?.+).domain.com$;

OR

server_name *.domain.com

The environment variable $_SERVER[SERVER_NAME] => ~^(?.+).domain.com$ is passed as this to php. As the package relying on $_SERVER[SERVER_NAME], it is not able to detect correct environment. But the $_SERVER[HTTP_HOST] is passed properly in this case.

Not sure it is an issue with the package or is there any work around to pass the server name properly from ngnix?

Thanks in advance.

gecche commented 3 years ago

Hi,

I'm not very skilled in server administration, so I can't help very much, apart from doing some tests in the weekend If I get some time.

I know that SERVER_NAMEis more reliable than HTTP_HOST, so I chose that variable for detecting the domain. However, in the future I would want to add a feature for customizing the detection of the domain, maybe passing a Closure as a further optional argument when constructing the App. It was a planned feature but I wondered about its usefulness...

For now, If you are not able to fix the Nginx settings (which would be the best: I think that It would be useful to have the SERVER_NAME variable properly set) you could simply fork the project and change the Gecche\Multidomain\Foundation\DomainDetector@detectWebDomain method using whatever you need.

I will let you know If I will be able to investigate in the Nginx settings.

Cheers

Giacomo

P.S.: If you liked the package please leave a star If you didn't yet :)

Epizefiri commented 3 years ago

Same problem here. I've a docker instance of laravel that answer to *.mydomain.app

I tried your package but the custom .env is ignored when i call the website from the browser ( it works from the command line )

Epizefiri commented 3 years ago

@gecche I tried to change SERVER_NAME in HTTP_HOST in the method Gecche\Multidomain\Foundation\DomainDetector@detectWebDomain and it actually works!

gecche commented 3 years ago

Hi all,

I did not have time this weekend to set up a wildcard Nginx demo. However I dug a bit on this issue and It seems to be related directly to Nginx as pointed out in this article where there are also two different solutions that could help with your specific configuration in Nginx:

https://serverfault.com/questions/650560/nginx-regex-vhost-pattern-ends-up-as-php-server-name

However, I think that, If possible, a better solution is to list explicitly your subdomains as ServerAlias in the Nginx configuration: I didn't try but it should work.

In the next release of the package (I think within two weeks) I will definitely add a further param to the main Application for customizing the domain detection function, so If the HTTP_HOST variable (or other logic) is needed can be passed accordingly. Note that it is not possible to put it as a standard config param as the config is loaded when the env is already loaded.

Let me know if the solutions proposed above helped you in some ways. I will inform you when the next release is ready.

Cheers

Giacomo

satheesh365 commented 3 years ago

Hi all,

I did not have time this weekend to set up a wildcard Nginx demo. However I dug a bit on this issue and It seems to be related directly to Nginx as pointed out in this article where there are also two different solutions that could help with your specific configuration in Nginx:

https://serverfault.com/questions/650560/nginx-regex-vhost-pattern-ends-up-as-php-server-name

However, I think that, If possible, a better solution is to list explicitly your subdomains as ServerAlias in the Nginx configuration: I didn't try but it should work.

In the next release of the package (I think within two weeks) I will definitely add a further param to the main Application for customizing the domain detection function, so If the HTTP_HOST variable (or other logic) is needed can be passed accordingly. Note that it is not possible to put it as a standard config param as the config is loaded when the env is already loaded.

Let me know if the solutions proposed above helped you in some ways. I will inform you when the next release is ready.

Cheers

Giacomo

@gecche , thanks for your reply and the reference link. The following nginx setup worked for me.

server_name ~^(?.+).example.com$; set $server_name_full $subdomain.example.com;

location ~ .php$ { ... include fastcgi_params; fastcgi_param SERVER_NAME $server_name_full; ... }

gecche commented 3 years ago

Thanks! I will publish it in the docs in the next release

jam0147 commented 3 years ago

Hello gecche,

Excellent this package, it simplifies the use of the multidomain a lot.

I'll give you the stars haha

You know we are having a similar problem with nginx and I have seen the file you commented to make the change:

Gecche \ Multidomain \ Foundation \ DomainDetector @ detectWebDomain

The only detail is that if I do composer install again (for some reason) that change will be erased.

We saw the classes you use to see if it could extend but the truth is I do not know if it will damage something else later.

What do you recommmend me to do?

I have the project with:

Laravel 5.7 gecche / laravel-multidomain 1.3

gecche commented 3 years ago

Hi!

Excellent this package, it simplifies the use of the multidomain a lot.

Thanks for your feedback!

I'll give you the stars haha

😄

You know we are having a similar problem with nginx and I have seen the file you commented to make the change:

Gecche \ Multidomain \ Foundation \ DomainDetector @ detectWebDomain

The only detail is that if I do composer install again (for some reason) that change will be erased.

We saw the classes you use to see if it could extend but the truth is I do not know if it will damage something else later.

What do you recommmend me to do?

Well, If you want to change the Gecche \ Multidomain \ Foundation \ DomainDetector @ detectWebDomain file, you have to fork the repository if you don't want that composer overrides the changes at every update.

However, my opinion is that is better to keep SERVER_NAME instead of HTTP_HOST in the domain detector as the former is more reliable and as confirmed by @satheesh365 the following Nginx configuration does the trick:


server_name ~^(?.+).example.com$;
set $server_name_full $subdomain.example.com;

location ~ .php$ {
...
include fastcgi_params;
fastcgi_param SERVER_NAME $server_name_full;
...
}

I planned to do a new release adding the possibility of customizing the detection function, but I had to do some not expected work, so I'm late... 😞

Cheers

Giacomo

jam0147 commented 3 years ago

I think we will opt for the fork, because the sysadmin tells us that in the future it may generate some conflicts with other developments.

Thank you very much for your answer !

gecche commented 3 years ago

Hi all,

I just updated the package with the possibility of customizing the domain detection function. So, e.g., if you prefer to rely upon HTTP_HOST, you can specify a Closure and pass it to the Laravel Application. There is an example in the docs.

Hope this is useful to all

Cheers

Giacomo