This is interesting:
I added this (contents of web-resource-collection omitted) to the top of
the context's web.inf, right below the "web-app" and "display-name" tags:
<web-resource-collection>
. . .
</web-resource-collection>
<auth-constraint/>
</security-constraint>
and restarted the context, and as advertised, all requests for anything
that matched the url-pattern tags in the web-resource-collection were
rebuffed with a default 403 message page. So far, so good.
But because I figured there was at least a remote possibility that there
might be reason to grant some people web access to the forbidden
resources, I tried another variation:
> <web-resource-collection>
. . .
> </web-resource-collection>
> <auth-constraint> <role-name>frobozz</role-name></auth-constraint>
> </security-constraint>
(note: "frobozz" is unknown to tomcat-users.xml). After restarting the
context, there was no change in behavior: no sign-on dialog; just
straight to a default 403 page.
I tried adding this to the web resource collection:
<http-method>GET</http-method>
<http-method>POST</http-method>
and adding this right below it:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>FOOBAR</realm-name>
</login-config>
<security-role>
<role-name>frobozz</role-name>
</security-role>
(note: there are, so far as I'm aware, no references to "FOOBAR"
anywhere on this particular Tomcat server). Again, after restarting the
context with this change in place, no change in behavior: it still
immediately serves a 403 page.
I looked over the web.xml in "manager," and I don't see a whole lot
that's structurally different.
Any idea what I could be doing wrong?
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
