Hi Chuck
Yes, you are perfectly correct. Security-constraint via
web.xml allows fine grain definition of the URI path: agreed.
And also, yes, because paths/URI's are fully specified in
the <security-constraint>...<url-pattern>..., their is an
inherent static nature to this.
As such, this is not suitable to the particular requirement
I had.
Which, in part, is why I built the mechanism that I
described.
I guess, had I my druthers, I would want to send to
DefaultServlet, along with the requested path, a
permission object or a permission-lookup-protocol
object so that DefaultServlet could serve or deny
the request for the give session based on this
accompanying object. Because this was not within
the responsibilities or capabilities of the DefaultServlet,
I had to resort to filtering the incoming request and only
then passing the modified request to DefaultServlet when
the request qualified.
Thanks again for helping me consider the options for
dealing with this kind of behavior.
Maurice Yarrow
Caldarale, Charles R wrote:
From: Maurice Yarrow [mailto:[EMAIL PROTECTED]
Subject: Re: Tomcat Security
BUT: the finest granularity for what can be accessed in this
mechanism is by servlet, not by the path info (getPathInfo())
of the URI.
Not true - security constraints apply to paths, not servlets. If you
want to see an example of multi-path constraints, download Lambda Probe
and look at its web.xml file.
(Remember, realm based authentic. allows access control
based on the enclosing Engine, Host, Context, or Wrapper,
a Wrapper being a servlet.)
A realm is merely an authentication credential repository, not an access
control mechanism. The servlet spec allows one to use the
<security-constraint> settings to define access controls.
However, the real mismatch here is the dynamic nature of your
environment. Since the accessiblity of a given path can change at any
moment, this doesn't fit with the essentially static nature of standard
servlet security.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
