What about libraries that contain statics which are independant of servlets
(e.g the servlets use them indirectly)? What does one do about these?
Are you saying that one can call any classes in the CLASSPATH?
dino
-----Original Message-----
From: A.W.F. Boer <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, October 08, 1999 5:28 AM
Subject: Re: QoW - How can I share objects among servlets?
>Don't know.
>
>The problem is sharing of a (not serializable) resource object between
services (i.e.
>servlet class+name pairs) NOT using public (or protected) static
methods/fields in
>a class accessible to servlets not belonging to your application.
>
>There are ways, I believe, to authenticate objects calling the resource in
a safe way.
>The difficult part is finding a way to create the resource safely in the
first place; for
>jdbc connections the solution can be simple. But that does not solve the
general
>problem: A system administrator cannot just put your jar file in the
CLASSPATH
>and trust you if it contains suspicious 'static' code.
>
>For you this need not be a practical 2.0 API problem, but I know at least
one 'secure
>communication' jar that relies on public static methods to create 'secure'
CORBA
>connections inside a private commercial system. It can be compromised if
you have
>either:
>
>1) the javadoc and a servlet in that environment, or
>2) a 'Trojan' servlet in that environment that uses reflection to inspect
it.
>
>I do not think that there is a viable solution using the 2.0 API, that's
why Sun is using
>the QoW to re-educate us on this subject. They realized there is a
potential problem
>if the people responsible for what is in the CLASSPATH of a webserver are
not java
>wizards (or if they are java wizards, but not very responsible
administrators).
>
>I am not a real expert on the possibilities with java.security.* packages
or server con-
>figuration (not my job, fortunately). Does anyone know safe 2.0 API
solutions?
>
>
>Alexander W. F. Boer
>Dept. of Computer Science and Law,
>University of Amsterdam, the Netherlands
>email: [EMAIL PROTECTED]
>
___________________________________________________________________________
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
