That is a valid, and very interesting point...
I did the request under port 80, and it loaded. I completely forgot that
I never enabled port 80.
This configuration is for port 443.
Again, I never configured it to listen to port 80.
So... where on earth did it get configured to listen on port 80 in the
first place? I never specified it to do that. There is no
NameVirtualHost *:80 anywhere in this configuration file (to clarify on
the other commenter, this is in sites-enabled/ and is the only file/link
in that folder)
Timothy D. Legg
> While testing, are you sure that youâ??re accessing it over HTTPS and not
> HTTP? If this is over normal HTTP, then none of your below configuration
> will apply.
>
> --
> Osama Elnaggar
>
> On December 1, 2017 at 11:39:11 PM, Timothy D Legg
> (apache@xxxxxxxxxxxxxxx)
> wrote:
>
> There is only one virtualhost active, so it is inherently unique.
>
> I tried the following:
>
> <Directory /var/www/html/graphs>
> <Directory /graphs>
> <Directory graphs/>
> <Directory /graphs/>
> <Directory graphs>
>
> I have not tried:
>
> <Directory /var/www/html/graphs/>
>
> but I suspect that this isn't where the problem lies.
>
> This is a privacy-sanitized edit of the exact conf file. By the way, I
> did reload the server on each modification.
>
>
> <IfModule mod_ssl.c>
> NameVirtualHost *:443
> <VirtualHost *:443>
> ServerName example.com
> ServerAdmin webmaster@localhost
>
> DocumentRoot /var/www/html
>
> ErrorLog ${APACHE_LOG_DIR}/error.log
> CustomLog ${APACHE_LOG_DIR}/access.log combined
>
>
> SSLEngine on
>
> SSLCertificateFile /vault/cert.pem
> SSLCertificateKeyFile /vault/key.pem
> SSLCertificateChainFile /vault/CAchain.pem
> SSLCACertificateFile /vault/2017.txt
>
> <FilesMatch "\.(cgi|shtml|phtml|php)$">
> SSLOptions +StdEnvVars
> </FilesMatch>
> <Directory /usr/lib/cgi-bin>
> SSLOptions +StdEnvVars
> </Directory>
> <Directory graphs>
> Require ip 172.12.33.177
> </Directory>
> </VirtualHost>
> </IfModule>
>
>
>
>> Make sure you are really landing in the same virtualhost with that
>> directory configuration.
>>
>> That may very well be an explanation to why it is not happening for
>> you. Remember to define a unique servername in each virtualhost,
>> different log names for each virtualhost, etc.
>>
>>
>> 2017-12-01 11:28 GMT+01:00 Timothy D Legg <apache@xxxxxxxxxxxxxxx>:
>>> In my scenario, that might work, and I appreciate the elegance of
>>> high-order switches to access. However, my exact question would lead to
>>> a
>>> more useful solution for myself and others.
>>>
>>> Lets consider, for example, I created a dashboard in PHP for modifying
>>> my
>>> SQL database. It would be best to have a user authentication written
>>> into
>>> the PHP, but I'm in a hurry and have a static IP so I think to myself,
>>> "Hey, this IP never changes. I'm the only one on my network. Lets block
>>> this access according to path and IP address. I'll put in 192.168.40.80
>>> and nobody else can get there unless they are physically in my house or
>>> logged in my console."
>>>
>>> Another case would be I might have an embedded system on manufacturing
>>> equipment that provides access to: an operator (x.x.40.70), a
>>> supervisor
>>> (x.x.40.80) and an IT technician (v.w.y.z). They may need to access
>>> certain restricted portions of the webserver from permanently fixed
>>> terminals an a piece of machinery. It might not be in the supervisor's
>>> interest to have the operator's web-dashboard be allowed to modify the
>>> parameters of the machine. The IT administrator would probably not want
>>> the supervisor accessing admin tools, such as phpmyadmin.
>>>
>>>
>>>> you could try /etc/hosts.deny
>>>>
>>>> On Fri, Dec 1, 2017 at 4:03 AM, Timothy D Legg
>>>> <apache@xxxxxxxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am wanting to restrict a subdirectory of a website to a single,
>>>>> maybe
>>>>> two, IP addresses.
>>>>>
>>>>> I will refer to this documentation:
>>>>> httpd.apache.org/docs/current/howto/access.html
>>>>> under the section "Access control by host".
>>>>>
>>>>> This document suggests that 'Allow', 'Order', and 'Deny' are
>>>>> deprecated,
>>>>> so I am avoiding using these going forwards. It decided to exercise
>>>>> this
>>>>> restriction with mod_authz_host. I verified that authz_core_module,
>>>>> authz_host_module, authz_user_module are enabled.
>>>>>
>>>>> I added these lines inside the <VirtualHost *:443> block:
>>>>>
>>>>> <Directory /var/www/html/graphs>
>>>>> Require ip 192.168.40.80
>>>>> </Directory>
>>>>>
>>>>> But a test revealed I was able to wget graphs/test.html on a
>>>>> different
>>>>> machine (192.168.40.81).
>>>>>
>>>>> I've only read the documentation. Practically every non-Apache
>>>>> website
>>>>> still uses Order-Allow-Deny methodologies, so it's still not clear
>>>>> how
>>>>> this is actually done in practice. Why did this not work?
>>>>>
>>>>> Thanks, Timothy D Legg
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>>>>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>>>
>>
>>
>>
>> --
>> Daniel Ferradal
>> IT Specialist
>>
>> email dferradal at gmail.com
>> linkedin es.linkedin.com/in/danielferradal
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|