DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19938>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19938 [PATCH] local access wildcard word: "Allow from Here" Summary: [PATCH] local access wildcard word: "Allow from Here" Product: Apache httpd-2.0 Version: HEAD Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: mod_access AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] [NOTE: tested on linux only, I don't have a suitable Windows test environment.] This is a basic enhancement to the mod_access module. It consists of ten lines of new code which adds "Here" as a wildcard word (like "all") as a fourth option to the Allow/Deny stanza. (Better minds than mine may think of a better word for this than "here" but most of the ones I could think of [e.g. 'this', 'server', etc.] didn't read as well or might be encounterd as host names. 8-) What this does: The "here" wildcard word allows (or denies) access if the remote and local addresses of the connection are the same according to apr_sockaddr_equal(). Why Bother: An interesting number of problems, particularly within PHP programs, involve the server fetching pages from itself. A larger set of less-interesting problems involve wanting to make a page or resource available on "this here local machine" (only or aditionally). The existing methodologies available for isolating these loop-back connections were limited or cumbersome or error prone. In particular, using "Allow from Here" preserves the loopback-only intent across NFS mounted volumes when used in .htaccess files, virtual host configurations, system configuration changes, and DHCP style address assignments. Using "allow from host.domain.tld", "allow from 127.0.0.1", and "allow from (explicit_ip_address)" each have issues. Example (of moderate complexity): (in httpd.conf) <Directory "/usr/local/apache2/cgi-bin"> Satsify any Order allow,deny Allow from here Authtype basic require valid-user AuthUserFile /some/file AuthName "Direct CGI Access" </Directory> The cgi-bin directory will now generally require an basic authentication login to access from any remote host. Local users can run the CGI "directly" without authenticating themselves. More interestingly, a PHP page can run the cgi programs using open("http://".$_SERVER["SERVER_NAME"]."/cgi-bin/DoWhatever"; (or similar variants) *WITHOUT* the user doing the basic authentication steps. "Allow from localhost" isn't enough to net this last feature because the PHP script, even when calling to localhost, calls "from" the servers explicit listening interface. This is also a safe comparison metric as the IP addresses are resolved within the server, making the test particularly resistent to DNS spoofing etc. As an added bonus, the test relies completely on the mature and feature-rich comparison function already existent within the api. Robert White Casabyte, Inc. Renton, WA. USA --- mod_access-old.c 2003-05-14 17:54:45.000000000 -0700 +++ mod_access.c 2003-05-14 17:37:37.000000000 -0700 @@ -87,6 +87,7 @@ T_ALL, T_IP, T_HOST, + T_HERE, T_FAIL }; @@ -173,6 +174,9 @@ else if (!strcasecmp(where, "all")) { a->type = T_ALL; } + else if (!strcasecmp(where, "here")) { + a->type = T_HERE; + } else if ((s = strchr(where, '/'))) { *s++ = '\0'; rv = apr_ipsubnet_create(&a->x.ip, where, s, cmd->pool); @@ -259,6 +263,12 @@ case T_ALL: return 1; + case T_HERE: + if (apr_sockaddr_equal(r->connection->local_addr, r->connection->remote_addr)) { + return 1; + } + break; + case T_IP: if (apr_ipsubnet_test(ap[i].x.ip, r->connection->remote_addr)) { return 1; --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
