portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory
Date Fri, 09 Mar 2001 12:02:14 GMT
David Sean Taylor wrote:

>> (David what did you
>> mean by "bug in the servlet container". Does this vendor
>> regard it as a bug
>> if it's not possible to forward the requests to JSPs below WEB-INF?)
> Their RequestDispatcher does not work. Simple as that.
> Regardless if forwarding/including from WEB-INF or any other directory.
> I have sent them simples examples. They have acknowledged this a bug.
> They are questioning whether JSPs in the WEB-INF directory should be
> accessible

This looks like defensive behaviour. Instead of acknowledging that they have
a broken requestDispatcher, they look for counterarguments.

> I understand your argument, but the simple fact is that other vendors may
> not see it this way, as this case testifies to.
> Even when they fix the bug with the dispatcher, I am not sure if they will
> allow for JSPs to be served from WEB-INF.

This will be the moment to look for a workaround or change in behaviour.

>> A second argument: if we move the templates up to the
>> web-root and protect
>> them so that they can't be requested by a client directly --
>> then where is
>> the difference to putting them in the WEB-INF??

The difference, Ingo, might be that a given app server runs or not. But we should not
go too fast here. David, maybe we can think about a workaround for this vendor, like
not using requestDispatcher or patching theirs. I suggest that if they don't react fast
enough to the issues you publish their name/version/issue details and we start looking for
 workarounds in their user community.

> Im undecided on all these issues, until I understand the overhead with
> secure resources.
> Perhaps the PSML could go under the web root, but in a secure directory.
> If we start using secure resources, does this require that Tomcat starts
> with a security manager?

Not at all (at least with tomcat 3.2.2beta). There are two different issues here:

- container authentication (= secure resources). No resource will be served
unless the client has authenticated first (password, form, etc.). Request should
return true to isSecure(), and return us a getUserPrincipal(). This Principal
can be used for isUserInRole( role ). This is HTTP authentication.

- java security. A SecurityManager is installed. Operations like Thread.stop() or new File()
are checked
for permissions, depending on code base and classloader info. This is analogue to running
as nobody vs.
running as root (in the java level). This is standard java security. Having java security
on is mandatory for 
RMI servers (and nothing else, as far as I know, JNDI? ).

Java security will possibly be used when a provider wants to ensure that different war apps
in the same VM without interference. For instance, without calling System.exit(), or writing
the files
of the other app. Also, if you VM runs at the same time a servlet container and a RMI server.
This could be
the case for some App servers.

> Also undecided on the database.
> Its obvious that in a real deployment, the database will not go there.
> Its just valuable for first time developers to easily get started with a
> default database.

Does the database runs correctly with this vendor's server? I bet yes. Let us go slowly on
this one again. 

A good question is:

Which App servers with servlet containers out there use a 
SecurityManager, mandatory or recommended, in their setup?

I remember Jonas required it if you were running the RMI server from the 
same VM. I did this for my customer one year ago, to simplify VM 
maintenance and memory footprint. (It would not run under jdk1.2.2, due 
to a silly classloader bug solved in jdk1.3) But, again, the servlet 
container was not included in this setup, so no problem for us. In my 
setup I had on VM for the web server, and another one for the RMI server 
and EJB container, both as NT services. I saved one NT service and java VM.

Can you all erase the rest of the message quote and answer this last 
question, for what you know?

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message