-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help with warning messages please #304
Comments
Browsers do not know how to do opportunistic authentication or how to remember that a directory is protected by authentication to do so. Whenever you have a resource protect by GSSAPI the request will come with no Authorization token, and GSSAPI will send back a 401 with a Negotiate Header, at which point the broswer understand SPNEGO/GSSAPI is required and fetches a ticket (if it doesn't have one yet) from the KDC and then sends an init context token in an Authorization header back to the same URL. On the second time the GSSAPI module can read the token and authenticate the request returning a 200 for existing underlying resources or a 404 when the resource is not found. Because of this browser sillyiness, what most people do is to have a dedicated login page (say /login.html) and they only protect that page via GSSAPI. If the cookie is not present the Error Document is customarily resolved to a redirect to the login page so authentication can be perfomed once, and that pages redirects back to the refferal page. mod_auth_gssapi can be configure to handle some of this automatically (ie without a special redirect page) via direct use of Session Cookies, see the Gssapi[Use]Session[Key] directives, requires installation of mod_session. |
Hi Simo I'm still wondering about these two mostly: The "Subrequest" line repeats for every different path viewed in viewvc. And I'm not sure how to fix the "Failed to lookup env table" one either. Thanks for your help and have a great weekend |
Sorry but these are all Apache Httpd questions, not mod_auth_gssapi ones. The location thing just means you have some configuration both in a <Directory> statement and a <Location> statement that change the same endpoint and Httpd is complaining about that. I suggest you use either Directory or Location and not mix the two. Generally Location is the more flexible option. HTH. |
Hi Simo Cheers |
If it turns out mod_auth_gssapi is doing something wrong, please let me know, I am happy to address any deficiencies in it. |
I'm using gssapi to authenticate access to a viewvc instance and I'm getting these warnings in the logs.
[auth_gssapi:warn] [pid 14398:tid 14439] [client xxx.xxx.xxx.xxx:52682] Subrequest authentication bypass on location with different configuration!
This is the apache config file for viewvc:
ScriptAlias /viewvc /var/www/viewvc-1.3.0/bin/cgi/viewvc.cgi
<Directory /var/www/viewvc-1.3.0>
SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire ( %{HTTP_HOST} eq "domain.com.au" )
ErrorDocument 403 https://domain.com.au/viewvc
SSLVerifyClient require
AuthType GSSAPI
AuthName "GSSAPI Login"
GssapiBasicAuth On
GssapiNegotiateOnce on
Require valid-user
Options +ExecCGI
AddHandler cgi-script .cgi
I believe I've also seen another error that is a few lines further down in the mod_auth_gssapi.c code
"Failed to lookup env table in subrequest"
I'm just not sure what the root cause of these errors is?
What is the Main Request vs Sub request in these cases
These are what the requests look like in ssl_request_log:
[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /viewvc/docroot/scripts.js HTTP/1.1" 401 381 0 2
[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /viewvc/docroot/scripts.js HTTP/1.1" 200 49 0 3
[30/Apr/2024:12:54:33 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /favicon.ico HTTP/1.1" 401 381 0 4
[30/Apr/2024:12:54:34 +0800] 192.168.2.4 TLSv1.3 TLS_AES_256_GCM_SHA384 "GET /favicon.ico HTTP/1.1" 404 196 0 5
There is always a 401 followed by a 200 or 404 depending on the outcome
I think the 401 is due to Firefox being setup to use the MIT Kerberos tool for SSO. So I think it fails login before trying that each time for some reason..
The text was updated successfully, but these errors were encountered: