ent will be the easiest for them to see). Of course
for this matter to succeed the creation of a fully automated web.xml building
script will be required.
Thanks for the help.
Best regards,
Federico.
-Mensaje original-
De: Christopher Schultz [mailto:ch...@christopherschultz.net
). Of course
for this matter to succeed the creation of a fully automated web.xml building
script will be required.
Thanks for the help.
Best regards,
Federico.
-Mensaje original-
De: Christopher Schultz [mailto:ch...@christopherschultz.net]
Enviado el: jueves, 09 de juni
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Federico,
On 6/8/2011 2:04 PM, falva...@geocom.com.uy wrote:
> If this is the case I could make it weight-in in the matter of building a
> well formed web.xml.
>
> Although it could take some time.
How many servlets do you have?
> Mapping each serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Federico,
On 6/8/2011 10:17 AM, falva...@geocom.com.uy wrote:
>
> invoker
> /*
>
Why not map the invoker to "/servlet/*"?
Seems like that would fix your problem.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment:
On 08/06/2011 17:48, falva...@geocom.com.uy wrote:
> Currently we do not have this kind of attacks because the app runs in an
> intranet. But I know that in this closed scenario we should beware of the
> users.
But if your network is penetrated, your server will be vulnerable and
therefore a resou
nd keep images under
"/images".
Thanks a lot Tim and thanks to all.
Regards,
Federico.
-Mensaje original-
De: Tim Funk [mailto:funk...@apache.org]
Enviado el: miércoles, 08 de junio de 2011 14:53
Para: Tomcat Users List
Asunto: Re: Static resource mapping in web.xml
yes -
yes - that would be a problem. The invoker doesn't know how to serve static
resources.
-Tim
On Wed, Jun 8, 2011 at 1:44 PM, wrote:
> I agree with you.
>
> The static resources where never a problem to me, but since I messed with
> the web.xml they started to behave oddly.
>
> Maybe this line i
be interfering with the requests to resources?
-Mensaje original-
De: Tim Funk [mailto:funk...@apache.org]
Enviado el: miércoles, 08 de junio de 2011 14:09
Para: Tomcat Users List
Asunto: Re: Static resource mapping in web.xml
If your images are in the correct directory then tomcat will
If your images are in the correct directory then tomcat will serve them for
you with its DefaultServlet. There should be nothing to do.
Then to serve resources via the invoker - this is where the filter is handy.
You declare the invoker servlet - but you do not map it. The servlet api
allows you t
leave this problems behind (and get new ones ;)).
Thanks again.
Best regards,
Federico.
-Mensaje original-
De: André Warnier [mailto:a...@ice-sa.com]
Enviado el: miércoles, 08 de junio de 2011 13:02
Para: Tomcat Users List
Asunto: Re: Static resource mapping in web.xml
falva
2011 12:44
Para: Tomcat Users List
Asunto: Re: Static resource mapping in web.xml
No - images will be served by the default servlet so nothing needs to be
done for images.
The filter is used as a way to let the invoker work and be a tiny bit more
secure. So the filter is mapped to /* and will forw
falva...@geocom.com.uy wrote:
I know we are going a little off the original topic, but for me this is very
interesting.
I think I understand your point:
Any library in /webapp/lib/ that has access to executing linux
commands (as you point) could be executed as well from any browser.
No - images will be served by the default servlet so nothing needs to be
done for images.
The filter is used as a way to let the invoker work and be a tiny bit more
secure. So the filter is mapped to /* and will forward anything to the
invoker serllet if the requested path *looks like one of your
resource mapping in web.xml
falva...@geocom.com.uy wrote:
...
>
> Invoker: I know it is bad (even more than the overlord), probably don't
know
> how bad or the impact it has in usage, but for now it works.
>
> I've read some about it, but never could really understand
mcat Users List
Asunto: Re: Static resource mapping in web.xml
Your "easiest" workaround is to use a filter.
So
1) have the default servlet map to /* (which is the default)
2) keep the invoker declared
3) And make your filter do this ...
doFilter(..) {
if (request.getServletPath(
falva...@geocom.com.uy wrote:
...
Invoker: I know it is bad (even more than the overlord), probably don't know
how bad or the impact it has in usage, but for now it works.
I've read some about it, but never could really understand the problems it
brings.
http://wiki.apache.org/tomcat/FAQ/Mis
List
Asunto: Re: Static resource mapping in web.xml
On 08/06/2011 15:17, falva...@geocom.com.uy wrote:
> I have a WEBAPP which uses the "invoker" servlet (i know
how
> bad it is, but for now it gets the job done).
That is such a monumentally bad idea I'm not at al
Your "easiest" workaround is to use a filter.
So
1) have the default servlet map to /* (which is the default)
2) keep the invoker declared
3) And make your filter do this ...
doFilter(..) {
if (request.getServletPath().matches(regex-here)) {
servletContext.getNamedDispatcher("invoker").for
On 08/06/2011 15:17, falva...@geocom.com.uy wrote:
> I have a WEBAPP which uses the "invoker" servlet (i know how
> bad it is, but for now it gets the job done).
That is such a monumentally bad idea I'm not at all sure you really do
understand just how bad it is.
>
19 matches
Mail list logo
