First of all, I have to admit I am also puzzled at why, when the proxy offers a challenge, it uses WWW-Authenticate instead of Proxy-Authenticate. That may be a hint, or it may be a distraction.

But the immediate problem is this: I am trying to configure Apache to run on port 8080 as a proxy only, accessible without password for machines on my LAN, but accessible only after a challenge to machines outside. Right now, I am using Basic authentication, but I certainly plan to leave it enabled only after it has been switched to Digest.

The first part works: I can access the proxy from inside. But the second fails: I get a password challenge, but it always fails to accept even valid user/pwd.

So for now, I am using the following lines in httpd.conf:

<IfModule mod_proxy.c>
ProxyRequests On
ProxyVia On
<Proxy *:8080>
Require valid-user
AuthName "ClosedProxy"
AuthType Basic
AuthUserFile /home/mejohnsn/xanthusPwdFileBasic
Order allow,deny
Allow from 192.168.0.0/255.255.255.0
Satisfy Any
</Proxy>
</IfModule>

I also tried moving the Require directive, replacing 'valid-user' w/
'user mejohnsn, and AuthName both with and w/o quote marks.

Other points: yes, I made sure user:group 'apache' has read
permissions on the file. I made sure it has the modules,
mod_auth_basic and mod_authn_file.

In fact, when I print out using httpd -M and grep for auth, I see:

auth_basic_module (shared)
auth_digest_module (shared)
authn_file_module (shared)
authn_alias_module (shared)
authn_anon_module (shared)
authn_dbm_module (shared)
authn_default_module (shared)
authz_host_module (shared)
authz_user_module (shared)
authz_owner_module (shared)
authz_groupfile_module (shared)
authz_dbm_module (shared)
authz_default_module (shared)
authnz_ldap_module (shared)

and grepping for proxy:

proxy_module (shared)
proxy_balancer_module (shared)
proxy_ftp_module (shared)
proxy_http_module (shared)
proxy_connect_module (shared)


So I think I have all the modules I need.

As expected from following the online docs, the above "Order ... Any"
lines correctly force password authentication when connecting from
outside the firewall, allowing use of proxy w/o login when from within
the LAN.

I also tried both with and w/o the '-m' in: "htpasswd -m -c xanthusPwdFileBasic mejohnsn".

Finally, of course, I am running Fedora 14 and Apache 2.2.17.

Hi,

You should use the following:
Regards

What will this do for me? The IP based access control is already working. How would this help the authentication challenge, which happens but always fails?

Did you try it? This way it denies access to anyone unless "Satisfy Any" occurs.
You need the above change if you want to allow access either by IP or by username/password

Hi, bathory. Thanks for getting back to me. Now I know it sounds rude and counter-productive not to even try it, but please understand there were two reasons for this: 1) I have been inside the LAN all day today so far, I don't have a point outside I can try this from until later 2) your proposed change certainly does look correct, but I can't see how it addresses the problem at hand, the Order/Allow directives I already have are already doing that selection correctly (though after reading your lines, I have to admit it looks like mine should have failed -- but I copied mine out of Apache's own samples in the online docs). When outside the LAN, I DO get a password challenge. When inside, I do not. So far, that is exactly what I want; the problem is that the challenge is still not being done correctly.

So I will try your change later today, but I still cannot see how it could help. I will update this thread with the results in either case.

I've tried your Order directive here along with basic auth and it works too. I thought that using deny first, should make the server to force client to authenticate.
Anyway if you are prompted for username/password, but cannot authenticate, check the apache error_log to see if you find the reason.

Thanks again for getting back to me. I tailed the log while doing the access yesterday -- nothing! I didn't even get anything in access_log. If I hadn't been watching in Wireshark also and seeing the packets go across, I would have thought I wasn't hitting the server at all. And I have LogLevel debug, so I should see anything, right?

As for the Order directive, as I read the online Apache docs, the second parameter for the Order command is the default. Since I had "allow,deny", I did not need an explicit deny, it was the default. I think relying on the default makes for less readability, but it explains why the Apache example works.

So we are back to the basic problem: why I see a password prompt, but it rejects the one user/pwd combo defined. Also, why it displays the wrong realm. I set the realm explicitly to 'ClosedProxy' (see my original post this thread), yet what I see is always some long winded message, a default set by someone else.

BTW: I am not sure it is relevant, but I am also seeing it sometimes return "404 not found" instead. But at least once, when I cleared cookies and history, I got it to return "401 not authorized" again. I haven't figured out the pattern yet, since I tried clearing both again, yet still get 404.

But I still get no errors in error_log, I can watch the client do a GET http://www.ipl.org/div/special/ HTTP/1.1 (in Wireshark). So httpd thinks it is doing exactly what it was told to do

Finally, since I did get the 401 again, I can see the long wordy message it is using for the realm: "Before configuring the Gateway, a User Name / Password is required. If you do not know the User Name / Password please refer to the User manual for further support." That is not the realm I specified! This suggests to me that Apache is still not processing the AuthName directive -- for some mysterious reason. And this is the sole occurrence of AuthName in the whole file.

Anyway, thanks for your time, and please do let me know if you think of any other things I should investigate or try.

Hi,

Are you sure you're watching the correct logfile? There should be everything written in there with the username and a 401 code before authentication


Check if there is a .htaccess file inside the docroot directory.

What other logfile should I be looking for? I have "ErrorLog logs/error_log" in the config file, httpd.conf. /var/log/httpd/error_log is the one I tailed (I usually do "tail -f error_log" before doing a GET).

As for .htaccess, I already thought of that: no, there are none, and I have "AllowOverride None" anyway (outside of any container, in the "server config" context).

Now back to the error_log file: here is a pretty typical output after I to "httpd -k restart" and try one Http GET:

[Thu Mar 08 19:49:08 2012] [info] Server built: Oct 27 2010 10:04:08
[Thu Mar 08 19:49:08 2012] [debug] prefork.c(1018): AcceptMutex: sysvsem (default: sysvsem)
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 11390 for worker proxy:forward
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1837): proxy: worker proxy:forward already initialized
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 11390 for (*)
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 1 in child 11390 for worker proxy:reverse
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1837): proxy: worker proxy:reverse already initialized
[Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1934): proxy: initialized single connection worker 1 in child 11390 for (*)
[Thu Mar 08 19:55:49 2012] [info] removed PID file /etc/httpd/run/httpd.pid (pid=7401)
[Thu Mar 08 19:55:49 2012] [notice] caught SIGTERM, shutting down

One of the things that concerns me is that it mentions reverse already initialized: since I have one occurrence in server context (formerly in <IfModule> block) of ProxyRequest On, and none of ProxyPass, I do not understand why a reverse proxy is initialized at all. Nor why forward is -already- initialized. But there is no mention of the attempted access here or in access_log. Yet I can see the HTTP transaction in Wireshark.

I hope this does not leave you feeling as stymied as it does me Again, I look forward to whatever observations/suggestions you might have.

Then again, after writing the above, it occurred to me: is the problem ServerName? I had it set to the 'inside' IP address of the proxy in the 192.168.0.0 block. But outside, of course, it has another IP address. What impact does the differing IP address really have and how should I deal with it? I would try ServerAlias, but the online docs seem to say that is for Virtual Hosting only, which I no longer do (my setting of ServerName is left over from when I was trying that).

I thought that you might use different logfiles for different aspects of your apache. Anyway you should see a 401 or 407 code in both error_log and access_log if you are trying to authenticate to this apache server.


I don't know what to say. No .htaccess and yet you get a different realm than the one you use in AuthName!!! You can do a find/grep inside the apache config directory and maybe the docroot to see if you find where it gets that long realm


Maybe it's the way apache logs things in debug mode.

For the rest, I don't think that ServerName is that important. But you can put all your proxy stuff inside a vhost container like this:
Note the <Proxy *>

Hi, bathory-

Yes, I could, but the only difference between that and what I already tried is that 1)you are giving up on the restriction of the proxy to port 8080 and 2) you are leaving the default server doing who-knows-what. That looks like it introduces more complications we really don't need as long as we don't understand where that value for realm is coming from.

Besides: if that makes the difference, then isn't there a bug in Apache? Yet Googling has turned up no such report.

I will keep this suggestion in mind, but at this point in time, I think there are more promising avenues to investigate. I will update the thread if I find something.

And about your exclamation points, yes, you got that exactly right, and I am just as amazed! Either there really is a bug in Apache such that it is finding that Realms somewhere else, or the indentation got screwed up in my httpd.conf and I don't know when I am really in what context.

One final note for now: when I give up on distinguishing between inside and outside using the following for the <Proxy> section, I get it working, even using Proxy-Authenticate (instead of WWW-Authenticate) only when going to the proxy from inside the firewall!

The current <Proxy>:

ProxyRequests On
ProxyVia On

<Proxy *>
Order deny,allow
Allow from all
AuthType Basic
AuthName "Password Required"
AuthUserFile xanthusPwdFileBasic
Require valid-user
</Proxy>

all the above in server config context (assuming indentation correct).

Oh, I have two more questions that I think would help to have answered, perhaps you can help with that: 1) what does 'ProxyVia' really do, anyway? The Apache docs are skimpy on explaining this. 2) now that you know I have no .htaccess files, what else do I have to do to be sure no other configuration files are loaded? I realize that without the '-f' option, httpd assumes <ApacheRoot>/conf/httpd.conf, but don't I have to check for includes, too?

Anyway, thanks for your help so far.

You are not going to believe what fixed it: it was giving up on using port 8080 alone, reverting to port 80. Now it works both from inside and outside the LAN. This makes no sense to me, but I can live with it, so I changed the sole Listen directive to "Listen 80" in place of "Listen 8080".

Glad to see you've made it, even though I still wonder why it works when apache listens on port 80 and not when it listens on port 8080

I had to do this, because I've tested the configuration on a test box running apache as a normal webserver on port 80.


The ProxyVia controls the Via header(s).
For an explanation of the Via header see #14.44 here


Sure you need to check the main httpd.conf for lines that include other configuration files

Regards