On Tue, 18 May 1999, Craig R. McClanahan wrote:
>...........
> The data stored with context.setAttribute() is only "public" within a particular
> servlet context. If you don't trust the code in a servlet written by someone else,
> set it up in it's own context and you don't have this risk.
>...........
If ServletContext is safer within JSDK2.1 then perhaps servlet
API designers should consider un-deprecate getServlet(by-its-name) too,
the security issues that deprecated this call won't apply now neither.
And prevent retrieving servlet contexts and their contents by
context-names, for security reasons.
Or even go with flexibility further, like:
- allowing an already
init()-ialised servlet to register/remove other servlets within its own
context, as a deployment facility,
simplifying installation and configuration for applications made
from multiple servlets..
- having a security feature within servlet context through a call like:
allowServletPackage("my.own.servlet.package");
as a means for developers to prevent the run-time ServletContext
to load some other servlets even when administrators want to.
Eventually in conjunction with classloader + signatures security
scheme new in JDK1.2 wich is more difficult to keep track with.
Cezar.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
