Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory

[ingo schuster <in...@web.de>]

Man, you are all quick with our +1s...

My opinion is:
The WEB-INF is the only place that is per default save in a way that *under 
no circumstances* a client can request a file and gets it delivered by the 
HTTP server. This is very important with respect to security, and I 
wouldn't want to place any file that doesn't need to be served by the HTTP 
server somewhere else - unless there is a *very* good reason for doing so. 
This includes JSPs, they may contain comments and code that must not be 
viewed by clients. (The same holds true for logs, nobody apart the system 
administrators should be able to read them.)

"No file contained in the WEB-INF directory may be served directly to a 
client." means that it is not possible to send a request 
"http://myserver/myapp/WEB-INF/fileXY" and get it delivered *by the HTTP 
server*. A servlet, that receives a request under a different URL is of 
course allowed to read and deliver this file. It is also allowed to forward 
the request to another servlet in the WEB-INF/lib directory. JSPs are 
conceptually almost the same as servlets and I'd say that the servlet can 
_of course_ forward the request to a JSP below WEB-INF. (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?)
In short: I can't see how template processing is a _direct_ serving of a 
file - don't think that's fuzzy at all. Direct serving is the HTTP server 
picking up a file and delivering it, with no webapp code working inbetween.
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??

So I'm -1 for moving the templates to the web root. We only risk that we 
get additional problems with securing the directory there.



Writing in the WEB-INF is a problem, I can see this. I'm +1 for moving the 
cache to the work area - it is temporary data anyway.
Regarding the logs and the psml, I'm not sure what to do, I can see that 
they shouldn't be below WEB-INF, but I don't like to place them in a temp 
directory (that's what the work area is) - for production that's 
inacceptable. I agree with Santiago that a DB/LDAP would be the best place 
for a serious installation, but for development, I can't think of a really 
good place...


To sumarize: I'm

-1 for moving the 'templates' to the web root,
+1 for leaving them where thy are
-1 for moving the 'logs' to the web root,
+0 for moving them to the work area,
-0 for moving the 'cache' to the web root
+1 for moving them to the work area,

+1 for moving the psml out of WEB-INF
(-1 for moving them to the web root)
... no idea where to put them. A BLOB in the DB?


ingo.


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

RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory

[David Sean Taylor <da...@bluesunrise.com>]

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

Yes, thats not surprising.

> 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

How can JSPs work in a Model 2 without a dispather?

The bug must be fixed. Geez, its the damn servlet specification.
They must correctly implement the api.
How do they get away with that j2ee-compliant logo?

> 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 just one little person, but I do have a few ways to be heard.
You know what Im working on, what Im writing... :)

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

Yes, it works.
Agreed. We have to acknowledge that many of new users don't know how to
configure a database.
It is valuable to have a configured, working db right in the war
installation

>
> A good question is:
>
> Which App servers with servlet containers out there use a
> SecurityManager, mandatory or recommended, in their setup?
>
> Can you all erase the rest of the message quote and answer this last
> question, for what you know?
>

I can do research this for the two app.servers Im working with

btw -- have you seen this
http://www.flashline.com/components/appservermatrix.jsp



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

Re: Servlet 2.2 Spec. and serving files from the WEB-INF directory

[Santiago Gala <sg...@hisitech.com>]

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 run
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

RE: Servlet 2.2 Spec. and serving files from the WEB-INF directory

[David Sean Taylor <da...@bluesunrise.com>]

> (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
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.

> 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??

Again, the point Im trying to make is that its up to interpretation in the
WEB-INF directory.
Your interpretation is that it is allowed. Another vendor may interpret it
differently.
The goal is to the deploy Jetspeed on all compliant servlet containers, and
to minimize deployment issues for our users.
Thats why Im not for leaving the templates in the WEB-INF directory, since
it may not work with all containers.

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?

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.
Perhaps we should have two different war files, or is that more confusing?

I guess Im not so fast with my +1s :)



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