Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Tired from nginx non-sense
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Tired from nginx non-sense

LeviLevi Member
edited February 2021 in Help

So, I have migrated from Apache to wonderful world of Nginx. And of course it was a darn mistake... Simple problem on my hands provided on the snippet bellow:

server {
    listen              443 ssl http2;
    server_name         domain.tld;
    set                 $base /var/www/domain.tld;
    root                $base/;

        # restrict methods
    if ($request_method !~ ^(GET|POST|HEAD|OPTIONS|TRACE)$) {
        return '405';
    }

    # index.php
    index      index.php;

   # index.php fallback
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # handle .php
    location ~ \.php$ {
        include nginxconfig.io/php_fastcgi.conf;
    }

        location ~ /superfolder {
           allow  127.0.0.1;
           deny all;
           return 404;
        }

        location ~ /\.ht {
                deny  all;
        }
}

Now that "superfolder" access restriction part is not working. I mean, yes, I can't access domain.tld/superfolder but I can access domain.tld/superfolder/superscript.php

It drives me nuts! I tried these variations:

location ^~ /superfolder {
           allow  127.0.0.1;
           deny all;
           return 404;
}

And:

location ~ /superfolder/.*\.(php)$ {
           allow  127.0.0.1;
           deny all;
           return 404;
}

Anyone who has more experience with Nginx - help, I'am stuck.

«1

Comments

  • rm_rm_ IPv6 Advocate, Veteran
    edited February 2021

    Nginx configs are indeed the single worst thing about that server, check out Lighttpd instead.

    I can't access domain.tld/superfolder but I can access domain.tld/superfolder/superscript.php

    As for the question, try replacing

    location ~ /superfolder {
    with
    location /superfolder/ {

    And then if you want PHP to work in there also (but for 127.0.0.1) you will likely need to
    include nginxconfig.io/php_fastcgi.conf;
    in that secton too. Yes, hard to call this anything else than nonsense.

    Thanked by 1quicksilver03
  • fastcgi.conf is included, I just cut it out and left important bits in example :) .

    So, I should include fastcgi like so:

    location /superfolder/ {
               include nginxconfig.io/php_fastcgi.conf;
               allow  127.0.0.1;
               deny all;
               return 404;
    }
    
  • nfnnfn Veteran
    edited February 2021

    Try to use internal; inside the superfolder

  • rm_rm_ IPv6 Advocate, Veteran

    So, I should include fastcgi like so:

    I'd say yes, and why not just try it and return with does it work or not, instead of "should I" :)

  • Problem resolved. I just had to move this portion of config to the bottom:

        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }
    
  • Revert to Apache, no earlier than v.2.4. Add in the PHP-FPM module. You'll then find Apache is at least as fast as NginX whilst retaining all the versatility of Apache, including htaccess.

    It's not quite as simple as installing the module but not much more to do. Use a search including the name and release of your distro. It does vary slightly from distro to distro.

  • yoursunnyyoursunny Member, IPv6 Advocate

    I switched to Caddy last year. Everything is so intuitive.
    https://yoursunny.com/t/2021/yoursunny-com-caddy/

    Thanked by 1that_guy
  • location ~ /(superfolder) {
    deny all;
    return 401;
    }

  • The heck is all of this? Use Caddy.

    Thanked by 2yoursunny SLMob
  • Unless you have the IQ of a golden retriever, I suggest you stop using PHP and Nginx.

    Thanked by 1skorupion
  • Did this transition many years ago. Apache seemed so much easier to config, but nginx is so much more lightweight.

  • how about openlitespeed

  • ericlsericls Member, Patron Provider

    How about cowboy?

  • BoogeymanBoogeyman Member
    edited February 2021

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

  • Does caddy support mod_security, cloudflare ip resolution, cloudflare origin verification?

  • @LTniger said: Does caddy support mod_security, cloudflare ip resolution, cloudflare origin verification?

    I think you will have figure on your own. I couldn't find any good tutorials about that either. Looks like there is no built in support for that.
    https://caddyserver.com/docs/extending-caddy#complete-example
    https://caddy.community/t/tutorial-for-extending-caddy/7065/5
    https://caddy.community/search?q=mod security

    Thanked by 1yoursunny
  • yoursunnyyoursunny Member, IPv6 Advocate

    @Boogeyman said:

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

    No, you should not use ANY control panel.
    cPanel, Direct Admin, … should all be avoided.

    Infrastructure should be defined in code and committed to source control.
    When you make the webapp, it comes with the exact web server configuration needed to serve the webapp.

    This is the configuration of my website:
    https://bitbucket.org/yoursunny/yoursunny-website/src/0616b70e484bbb736185a7debb2e3addf8153fe5/http-server/?at=master

    • Caddyfile and nginx config for development and production environments
    • test script
    • build steps
  • You can try LiteSpeed. It's an Apache drop in replacement, but uses the same architecture nginx does, so it's fast.

  • JioJio Member

    @Kacey2002 said: You can try LiteSpeed. It's an Apache drop in replacement, but uses the same architecture nginx does, so it's fast.

    It would be nice if you disclosed your connection to Litespeed when recommending them

  • mike1smike1s Member
    edited March 2021

    @yoursunny said:

    @Boogeyman said:

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

    No, you should not use ANY control panel.
    cPanel, Direct Admin, … should all be avoided.

    Infrastructure should be defined in code and committed to source control.
    When you make the webapp, it comes with the exact web server configuration needed to serve the webapp.

    This is the configuration of my website:
    https://bitbucket.org/yoursunny/yoursunny-website/src/0616b70e484bbb736185a7debb2e3addf8153fe5/http-server/?at=master

    • Caddyfile and nginx config for development and production environments
    • test script
    • build steps

    hahahaha... Good luck getting your average person who just wants a website to learn this stuff. Let's come back to reality. Most people just want to click click, site built, and go back to their business.

    Thanked by 2jsg Ganonk
  • yoursunnyyoursunny Member, IPv6 Advocate

    @SWN_Michael said:

    @yoursunny said:

    @Boogeyman said:

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

    No, you should not use ANY control panel.
    cPanel, Direct Admin, … should all be avoided.

    Infrastructure should be defined in code and committed to source control.
    When you make the webapp, it comes with the exact web server configuration needed to serve the webapp.

    This is the configuration of my website:
    https://bitbucket.org/yoursunny/yoursunny-website/src/0616b70e484bbb736185a7debb2e3addf8153fe5/http-server/?at=master

    • Caddyfile and nginx config for development and production environments
    • test script
    • build steps

    hahahaha... Good luck getting your average person who just wants a website to learn this stuff. Let's come back to reality. Most people just want to click click, site built, and go back to their business.

    Click click, site built on AlphaRacks.
    Provider deadpools, and you create a thread about how you lose the site and don't have backup.

    Code code, site built with all the infrastructure and configuration and content on GitHub.
    CI/CD pipeline deploys the site to AlphaRacks that you got for $1.
    Provider deadpools, you take a refugee deal, update CI/CD pipeline, and your site is back in 30 minutes.

    Thanked by 2randomq bulbasaur
  • mike1smike1s Member
    edited March 2021

    @yoursunny said:

    @SWN_Michael said:

    @yoursunny said:

    @Boogeyman said:

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

    No, you should not use ANY control panel.
    cPanel, Direct Admin, … should all be avoided.

    Infrastructure should be defined in code and committed to source control.
    When you make the webapp, it comes with the exact web server configuration needed to serve the webapp.

    This is the configuration of my website:
    https://bitbucket.org/yoursunny/yoursunny-website/src/0616b70e484bbb736185a7debb2e3addf8153fe5/http-server/?at=master

    • Caddyfile and nginx config for development and production environments
    • test script
    • build steps

    hahahaha... Good luck getting your average person who just wants a website to learn this stuff. Let's come back to reality. Most people just want to click click, site built, and go back to their business.

    Click click, site built on AlphaRacks.
    Provider deadpools, and you create a thread about how you lose the site and don't have backup.

    Code code, site built with all the infrastructure and configuration and content on GitHub.
    CI/CD pipeline deploys the site to AlphaRacks that you got for $1.
    Provider deadpools, you take a refugee deal, update CI/CD pipeline, and your site is back in 30 minutes.

    Again... It's easier to teach people backups than CI/CD, github and systems administration, and we still can't convince people to backup their own stuff. Do you really expect that we can teach people this? We're far more likely to get rid of the shady providers in this space than we are to ever teach people CI/CD, git, and basic sysadmin. I see and understand what you're saying, it's just not realistic.

  • @yoursunny said:

    @SWN_Michael said:

    @yoursunny said:

    @Boogeyman said:

    @yoursunny said: I switched to Caddy last year. Everything is so intuitive.

    TL;DR, Would this be sensible to make a control panel around Caddy?

    No, you should not use ANY control panel.
    cPanel, Direct Admin, … should all be avoided.

    Infrastructure should be defined in code and committed to source control.
    When you make the webapp, it comes with the exact web server configuration needed to serve the webapp.

    This is the configuration of my website:
    https://bitbucket.org/yoursunny/yoursunny-website/src/0616b70e484bbb736185a7debb2e3addf8153fe5/http-server/?at=master

    • Caddyfile and nginx config for development and production environments
    • test script
    • build steps

    hahahaha... Good luck getting your average person who just wants a website to learn this stuff. Let's come back to reality. Most people just want to click click, site built, and go back to their business.

    Click click, site built on AlphaRacks.
    Provider deadpools, and you create a thread about how you lose the site and don't have backup.

    Code code, site built with all the infrastructure and configuration and content on GitHub.
    CI/CD pipeline deploys the site to AlphaRacks that you got for $1.
    Provider deadpools, you take a refugee deal, update CI/CD pipeline, and your site is back in 30 minutes.

    If you have backups, your site'll be back in 30 mins. The real solution here to start going after the scam artists in this space, and those who enable them.

  • Weird. I got this configuration

    location ~ /test {
        return 401;
    }
    

    and it is working perfectly

    What is your nginx version? I am using mainline with the version shown in image above.

  • Anyway guys, I think it is not reasonable to ask him to change immediately without even trying to help him solve this problem. It just clutter this thread.

  • rm_rm_ IPv6 Advocate, Veteran

    and it is working perfectly

    On the screenshot you are trying to load test.txt, whereas the OP's issue was still being able to load .php files, and the cause was them being not covered by the auth restriction due to their separate location ~ \.php$ { section.

    Thanked by 1Levi
  • LeviLevi Member

    @rm_ said:

    and it is working perfectly

    On the screenshot you are trying to load test.txt, whereas the OP's issue was still being able to load .php files, and the cause was them being not covered by the auth restriction due to their separate location ~ \.php$ { section.

    Exactly. Always put .php execution at the end.

  • Monkeyloop with bongwater.

  • @LTniger said:
    Problem resolved. I just had to move this portion of config to the bottom:

        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }
    

    Nice link to bookmark and read about order of Nginx request processing http://nginx.org/en/docs/http/request_processing.html

Sign In or Register to comment.