вт, 23 июн. 2020 г. в 00:16, Tim Düsterhus <t...@bastelstu.be>:

> Hi List,
>
> I was having a bit of off-list disagreement with Willy regarding how
> HAProxy ACLs should work and what (experienced) administrators may or
> may expect from them. I am arguing about something I believe many
> administrators might accidentally do incorrectly. I'm intentionally
> being vague here, to not spoil any results of this survey.
>
> Let's pretend I'm new to this list and send the following request for help:
>
> ---
>
> We are using an off-the-shelf PHP 7.2 application (think some bulletin
> board software), running behind nginx as the FastCGI gateway and static
> file server. In front of that nginx we are running HAProxy 2.0 in 'mode
> http'.
>


nginx can serve both static files and dynamic php in "try_files" approach.
i.e. "try to serve file statically if it exists and pass to php fastcgi if
not found"


like

location / {
   try_files $uri $uri/ @php;
}

location /admin/
   allow 192.168.0.0/16;
   deny all;
   try_files $uri $uri/ @php;
}

location @php {
    fastcgi_pass .....
}


as for IP observation there's couple of options - proxy protocol or
set_reaip_from
or restriction might be served on haproxy



>
> This off-the-shelf PHP application has an integrated admin control panel
> within the /admin/ directory. The frontend consists of several "old
> style" PHP files, handling the various paths (e.g. login.php,
> register.php, create-thread.php). During upgrades of this off-the-shelf
> software new files might be added for new features.
>
> My boss asked me to restrict the access to the admin control panel to
> our internal network (192.168.0.0/16) for security reasons. Access to
> the user frontend files must not be restricted.
>
> How can I do this?
>
> ---
>
> What kind of (configuration) advice would you give me? Do you have any
> concerns? I consider *anything* a valid answer here and I'd like to hear
> from both experienced admins and "newbies".
>
> I'll give the "solution" once I get some replies :-)
>
> Best regards
> Tim Düsterhus
>
>

Reply via email to