mod_shib not handling requests to a specific virtualhost
Wessel, Keith
kwessel at illinois.edu
Fri Jan 29 10:34:26 EST 2016
Scott,
It's definitely Apache returning the 404. We shut down Tomcat to make sure things still weren't getting through to it, even after removing the ProxyPass directives.
There are no application overrides in shibboleth2.xml, just the application defaults. It's a rather standard shibboleth2.xml.
So, you're suggesting that Apache and mod_shib aren't interpreting the URL prefix as one that should go to mod_shib, right? Any way you know of that we can see Apache working through this logic, such as turning logging up to debug?
Keith
-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Thursday, January 28, 2016 8:46 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: mod_shib not handling requests to a specific virtualhost
On 1/28/16, 9:40 PM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>I have a rather odd situation here that I haven't seen before. On an Apache server, requests to one of the virtual hosts of /Shibboleth.sso/* aren't getting grabbed by mod_shib. When the admin contacted me today, he had the root of the virtualhost being handled by mod_jk and Tomcat, and I thought that might be the issue, similar to mod_wsgi without a SetHandler shib Location block. We turned off everything in the virtualhost, though, other than the DocumentRoot, ServerName, and ServerAdmin keywords, and still /Shibboleth.sso/Login results in a 404.
If it's a 404 from Apache, that's one thing, but if it's from Tomcat or something, that obviously means it's passing through.
>The over all web server setup looks pretty standard from what I've seen. Can anyone think of a reason why /Shibboleth.sso would work on the main server but not for a specific virtualhost?
Depends what is returning the 404, but generally if it's Apache, it means that a request to that vhost does not believe its handlerURL in the SP is the URL you think it's supposed to be.
It maps the request to an applicationId, determines the effective handlerURL for that Application (default or overridden), and then checks to see if the request URL is prefixed by the handlerURL it computes. If not, it passes it through. That's why there's no explicit "handler" in Apache or MIME type, or any kind of script mapping like with IIS, it's done with URL comparison logic.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list