Directory points to a real filesystem path and does not need trailing slashes. Use: <Directory /var/www/html/graphs> AllowOverride none Require ip 172.12.33.177 </Directory> To make sure you are not landing in other virtualhost, check apachectl -S output, there can be none with the same servername as this one 2017-12-01 13:59 GMT+01:00 Osama Elnaggar <oelnaggar04@xxxxxxxxx>: > 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 > -- 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