servlet filter not working over virtual directories in tomcat

[Pradyut Bhattacharya]

Hi,
I  had configured virtual directories in glassfish3.x over which I could write 
filters.
For an example I could access files at c:/web from http://localhost/TestApp/web 
over which I could also place a filter at my web app's web/xml file with

dir_filter
/web/*
Unfortunately Tomcat 8.0 is not allowing me to write a filter 
above that. It simply ignores the filters and shows the content in the web 
directory.
The problem is anybody can access all of the files in the "web" folder.
Any how can we place filter over the virtual directories.
FYI - i have made the web app named "TestApp" and the virtual config is located 
at "$tomcat_dir/conf/Catalina/localhost" directory with the file name 
"TestApp#web.xml" file and having the content 

The question is also at stackoverflow - 
http://stackoverflow.com/questions/33290483/servlet-filter-not-working-over-virtual-directories-in-tomcat
Tomcat bugzilla - https://bz.apache.org/bugzilla/show_bug.cgi?id=58523

RegardsPraddy, India  

Re: Question for posgresq, and jdbc.jar placement.

[Christopher Schultz]

Jose,

On 10/22/15 2:22 PM, Jose María Zaragoza wrote:
> 2015-10-22 18:26 GMT+02:00 Christopher Schultz :
>> Ognjen,
>>
>> On 10/22/15 9:10 AM, Ognjen Blagojevic wrote:
>>> Jose & Chris,
>>>
>>> On 21.10.2015 20:47, Christopher Schultz wrote:
 Jose,

 On 10/21/15 7:33 AM, Jose María Zaragoza wrote:
> IMHO
>
> $CATALINA_HOME/lib  would be the right place

 +1
>>>
>>> Are you willing to elaborate why do you prefer $CATALINA_HOME instead of
>>> $CATALINA_BASE?
>>>
>>> I don't have multiple Tomcat instances running, but I still split
>>> $CATALINA_HOME and $CATALINA_BASE to different directories in order to
>>> make Tomcat upgrades easier. Everything that is different from original
>>> installation goes to $CATALINA_BASE (bin/setenv.sh, conf/*, logs,
>>> webapp, etc... as well as additional jars including lib/(jdbc).jar. Thus
>>> when I upgrade Tomcat and change $CATALINA_HOME I don't have to think
>>> about additional jars.
>>
>> Our build process auto-builds CATALINA_BASE and so it's (marginally)
>> more convenient to have it in CATALINA_HOME. We also have 4 applications
>> running on each server from the same CATALINA_HOME and different
>> CATALINA_BASEs, but they all use the same JDBC driver.
>>
>> IMHO, it doesn't matter which one you use. I would have +1'd Jose
>> whichever one he said.
> 
> Cool !
> 
>> Honestly, CATALINA_BASE is probably much better,
>> since it won't interfere with other applications that might not need the
>> driver, or might require a different version, etc.
> 
> Honestly I've never needed to use CATALINA_BASE
> But I 've a question
> 
> every instance uses only its CATALINA_BASE directories or there is any
> kind of delegation hierachy for libraries ?
> 
> For example,if my webapp doesn't find a jar file on $CATALINA_BASE/lib
> , doest it search on $CATALINA_HOME/lib ?

Yes: the server's ClassLoader prefers JAR files found in CATALINA_BASE
over CATALINA_HOME. But if they conflict in odd ways, there can be
problems. I can't really think of a good example off-hand, but users
seem to find ways of shooting themselves in the foot with the
ClassLoaders quite well.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

/manager/text/list

[Chris Gamache]

Hi all,

Using Tomcat 8 ...

Has anyone noticed that /manager/text/list doesn't show version numbers
when there are multiple versions of a webapp running (via parallel
deployment)?

Is there a different listing facility I should be using to find out the
version tags of the currently running applications?

CG

Re: Question for posgresq, and jdbc.jar placement.

[Jose María Zaragoza]

2015-10-22 18:26 GMT+02:00 Christopher Schultz :
> Ognjen,
>
> On 10/22/15 9:10 AM, Ognjen Blagojevic wrote:
>> Jose & Chris,
>>
>> On 21.10.2015 20:47, Christopher Schultz wrote:
>>> Jose,
>>>
>>> On 10/21/15 7:33 AM, Jose María Zaragoza wrote:
 IMHO

 $CATALINA_HOME/lib  would be the right place
>>>
>>> +1
>>
>> Are you willing to elaborate why do you prefer $CATALINA_HOME instead of
>> $CATALINA_BASE?
>>
>> I don't have multiple Tomcat instances running, but I still split
>> $CATALINA_HOME and $CATALINA_BASE to different directories in order to
>> make Tomcat upgrades easier. Everything that is different from original
>> installation goes to $CATALINA_BASE (bin/setenv.sh, conf/*, logs,
>> webapp, etc... as well as additional jars including lib/(jdbc).jar. Thus
>> when I upgrade Tomcat and change $CATALINA_HOME I don't have to think
>> about additional jars.
>
> Our build process auto-builds CATALINA_BASE and so it's (marginally)
> more convenient to have it in CATALINA_HOME. We also have 4 applications
> running on each server from the same CATALINA_HOME and different
> CATALINA_BASEs, but they all use the same JDBC driver.
>
> IMHO, it doesn't matter which one you use. I would have +1'd Jose
> whichever one he said.

Cool !

>Honestly, CATALINA_BASE is probably much better,
> since it won't interfere with other applications that might not need the
> driver, or might require a different version, etc.

Honestly I've never needed to use CATALINA_BASE
But I 've a question

every instance uses only its CATALINA_BASE directories or there is any
kind of delegation hierachy for libraries ?

For example,if my webapp doesn't find a jar file on $CATALINA_BASE/lib
, doest it search on $CATALINA_HOME/lib ?

Regards




>
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SSL and Virtual Hosting

[Christopher Schultz]

Björn,

On 10/22/15 3:49 AM, Björn Raupach wrote:
>> On 21 Oct 2015, at 21:44, Christopher Schultz  
>> wrote:
>>
>> Björn,
>>
>> On 10/21/15 2:47 PM, Björn Raupach wrote:
 On 21 Oct 2015, at 20:42, Mark Thomas  wrote:

 On 21/10/2015 16:27, Björn Raupach wrote:
> Dear group,
>
> it would be nice if anyone knows, if my planned setup is going to work.
>
> At the moment we are having two services (web apps) at two different 
> machines and hostnames. Lets say bob.example.com and alice.example.com 
>
> bob.example.com runs without SSL and deploys the web app at the root 
> context. We just throw a ROOT.war in /webapps.
>
> alice.example.com needs SSL at all times. It currently does not run with 
> the root context but we would like to. So another ROOT.war. We have an 
> SSL cert for alice.example.com
>
> I want both applications to run on a single Tomcat instance with Virtual 
> Hosting. Virtual Hosting with Tomcat that is. I am comfortable with 
> setting up Virtual Hosting, but I am just not sure about the SSL part. 
> Does the choice between IP-based or Hostname matter? bob.example.com 
> might need SSL support in the future.
>
> We are using Amazon AWS if that is important. So I could get another 
> Elastic IP. We are working with the latest Apache Tomcat 8 and the latest 
> JDK on the server machines.
>
> Sorry if this is not 100% Tomcat related.

 Currently it will work if both hosts can share the same certificate
 because they share a connector and (currently) a connector can only have
 a single certificate.
>>>
>>> How can both hosts share the same certificate?
>>
>> I think he meant that if both sites "can" share a certificate, the whole
>> thing becomes easier. For example, a certificate with a
>> subject-alternative-name, or a wildcard certificate.
>>
>> Recent versions of Java support SNI which should allow multiple
>> certificates to be used, but I'm not sure if Tomcat supports that
>> directly right now (see Mark's comments about multi-certificate support
>> in the very near future).
>>
>>> Do I need a SAN certificate or can I just run with the cert for
>>> alice.example.com  and have to live with any
>>> cert errors on bob.example.com ?
>>
>> Well, those are both options, but the first one costs a heap of money
>> and the second is unpalatable for users (errors = bad).
>>
 As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
 to have per host certs. There should be a 9.0.0-RC1 in the next week or so.
>>
>> This is the "holy grail" of TLS certificate support -- one that I hope
>> will be able to be back-ported without too much pain for (probably) Mark.
>>
>> IIRC, this will also allow *either* PEM-file-based setup *or*
>> keystore-based setup regardless of the crypto implementation (OpenSSL
>> vs. JSSE) being used. I personally detest keystores because they are so
>> fault-intolerant, but they do have the advantage of being able to say
>> "use any matching certificate in this blob" to get work done.
>>
>> So... if you are willing to wait a bit (9.0-RC1 in the next week? woah!)
>> for a back-port from trunk into the 8.0.x branch, then that's probably
>> your best bet. If you absolutely need to get this out right away, I see
>> only a few options:
>>
>> 1. Wildcard cert
>> 2. Cert with a SAN
>> 3. Front each service with AWS ELB
>> 4. Front both services with httpd, which supports SNI
>> 5. Use two s, each on a different port
>> 6. Use two s, each on a different interface
>>
>> That last one (6) might not be possible on AWS, since the host is itself
>> mostly unaware of the public IP address external clients use to access
>> it. (I have an EC2 instance with both internal and external IPs, and I
>> only have "lo" and "eth0" interfaces, so I couldn't bind a 
>> to the public IP's interface).
>>
>> Option #3 might be the best for you in the short-term (and possibly the
>> long-term), because it allows you to easily configure TLS *and*
>> port-redirection without the complexity of a whole server+httpd instance
>> to maintain. It will also allow you to grow your service trivially in
>> the future should you choose to do so. The downside is that you pay for
>> the ELB by the bit-transferred. It's up to you to decide how much you're
>> willing to pay for that kind of thing.
> 
> I go with your option #3. AWS ELB is new to me but I have a look. In the
> end it is probably cheaper than paying another EC2 instance. 

I forgot that there is a fixed cost to running the load balancer of (as
of this writing) US0.025/hr, which is US219.15/yr. You can pay less for
an EC2 instance, but ELB is /very/ reliable, scales essentially
infinitely without your interference, and does not require management of
any kind (e.g. keeping OS packages up-to-date, etc.). You can connect it
up to any number of back-end EC2 instan

Tomcat returning context path with extra leading slash (was: Re: Tomcat not properly fully-qualifying redirect URLs)

[Christopher Schultz]

All,

On 10/14/15 11:03 PM, Christopher Schultz wrote:
> All,
> 
> On 7/3/15 1:40 PM, Christopher Schultz wrote:
>> Running Tomcat 8.0.x trunk as of 167 (slightly old) on
>> jdk1.8.0_45 on Mac OS X, I'm having intermittent problems with
>> Tomcat appearing not to change a relative URL into a
>> fully-qualified URL for redirection purposes.
> 
>> Since it's intermittent, it's hard to catch. But I just found a
>> case.
> 
>> I have an HttpServletResponseWrapper that logs calls to
>> sendRedirect() by dumping-out the URL that was passed-into the
>> sendRedirect method.
> 
>> [snip]
> 
>> [HttpServletResponse.sendRedirect or similar is ruining my redirect
>>  URL, so the hostname is being obliterated and I get 
>> http://context/path/to/page instead of 
>> http://localhost/context/path/to/page]
> 
> I'm having this problem, again. This time with an updated 8.0.x trunk
> (pretty much 8.0.27).
> 
> It might be a problem with securityfilter, which is trying to do this:
> 
> // redirect to login page
> response.sendRedirect(response.encodeRedirectURL(request.getContextPath(
> )
> + loginPage));
> 
> The "loginPage" variable starts with a "/" and the final URL *should*
> be something like "/context/loginPage", but by the time it gets to
> HttpServletResponse.sendRedirect, it's been changed to
> "//context/loginPage". This ruins everything, of course.
> 
> I haven't stepped-through the code in a debugger, yet, but all the
> code in both securityfilter and Tomcat looks okay at first glance.
> 
> The good news is that HttpServletResponse.sendRedirect isn't making a
> bad decision. It's either securityfilter itself, or some weird
> combination of a few components, since
> o.a.c.connector.Response.encodeRedirectURL doesn't mutate the URL in a
> way that could add leading slashes.

Okay, I caught this happening again.

I have this class wrapping the request object in a Filter that does
other things -- I just re-purposed it in order to catch this problem:

static class RequestWrapper
extends HttpServletRequestWrapper
{
RequestWrapper(HttpServletRequest request)
{
super(request);
}

public String getContextPath()
{
String contextPath = super.getContextPath();

org.apache.log4j.Logger.getLogger("redirect").info("contextPath=" +
contextPath);
return contextPath;
}
}

I got an error with the redirect, and this is what I have in my log file:

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
contextPath=//mycontext

(Note the // prefix.)

My application is deployed into an exploded WAR directory with a
META-INF/context.xml file that (correctly) declares neither a docBase
nor a path.

Later, when the redirect actually happens, the sendRedirect method
observes this:

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
encodeRedirectURL before encoding url=//mycontext/somepath¶meters


2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect-
encodeRedirectURL after encoding url=//mycontext/somepath¶meters

2015-10-22 13:47:33,367 [catalina-exec-6] INFO  redirect- sendRedirect:
location=//mycontext/somepath¶meters

Any idea what might be causing Tomcat to return "/" + context path when
ServletContext.getContextPath() is called?

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question for posgresq, and jdbc.jar placement.

[Christopher Schultz]

Ognjen,

On 10/22/15 9:10 AM, Ognjen Blagojevic wrote:
> Jose & Chris,
> 
> On 21.10.2015 20:47, Christopher Schultz wrote:
>> Jose,
>>
>> On 10/21/15 7:33 AM, Jose María Zaragoza wrote:
>>> IMHO
>>>
>>> $CATALINA_HOME/lib  would be the right place
>>
>> +1
> 
> Are you willing to elaborate why do you prefer $CATALINA_HOME instead of
> $CATALINA_BASE?
> 
> I don't have multiple Tomcat instances running, but I still split
> $CATALINA_HOME and $CATALINA_BASE to different directories in order to
> make Tomcat upgrades easier. Everything that is different from original
> installation goes to $CATALINA_BASE (bin/setenv.sh, conf/*, logs,
> webapp, etc... as well as additional jars including lib/(jdbc).jar. Thus
> when I upgrade Tomcat and change $CATALINA_HOME I don't have to think
> about additional jars.

Our build process auto-builds CATALINA_BASE and so it's (marginally)
more convenient to have it in CATALINA_HOME. We also have 4 applications
running on each server from the same CATALINA_HOME and different
CATALINA_BASEs, but they all use the same JDBC driver.

IMHO, it doesn't matter which one you use. I would have +1'd Jose
whichever one he said. Honestly, CATALINA_BASE is probably much better,
since it won't interfere with other applications that might not need the
driver, or might require a different version, etc.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Class Loader Problems with Tomcat 8 + Ant Task

[Jins Abraham]

M

Sent from my iPhone

> On Oct 15, 2015, at 10:15 AM, Amit Lonkar  
> wrote:
> 
> Any ideas on this one? 
> 
> 
>> On Oct 5, 2015, at 5:11 PM, Amit Lonkar  wrote:
>> 
>> Hi Chris
>> 
>> Any ideas why the Ant Task might be failing in Tomcat 8? 
>> Yes the application works on a clean fresh tomcat 7 but not on tomcat 8.
>> 
>> We have a Administrator application that is used for patching our scheduling 
>> software. The patch includes the war files and get deployed to all nodes 
>> using the Ant Task.
>> 
>> Thanks
>> Amit
>> 
>>> On Sep 25, 2015, at 2:47 PM, Christopher Schultz 
>>>  wrote:
>>> 
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>> 
>>> Amit,
>>> 
 On 9/24/15 2:24 PM, Amit Lonkar wrote:
 We are trying to upgrade from Tomcat 7 to Tomcat 8. One of the 
 functionalities we have is to deploy a war file using the
 DeployTask class. I have a simple test servlet that uses the
 DeployClass.
>>> 
>>> Stop right there.
>>> 
>>> You have a servlet that is using the DeployTask for something? That
>>> sounds ... astoundingly weird to me. Can you explain this use case?
>>> The only thing I can think of is a web application used to deploy web
>>> applications.
>>> 
 I keep getting he following exception. I have ant 1.9.6 and 
 catalina-ant-8.0.26 in the class path. The maven project is
 attached. Works fine on Tomcat 7.0.64 but not on Tomcat 8.0.26.
 
 *Tomcat Version: *8.0.26 *Java:* jdk1.8.0_45 *OS:* OSX *Class
 Path:*
 
 * ant-1.9.6 * ant-launcher-1.9.6 * javax.servlet-api-3.1.0 *
 tomcat-api-8.0.26 * tomcat-catalina-ant-8.0.26 *
 tomcat-juli-8.0.26 * tomcat-servlet-api-8.0.26 *
 tomcat-util-8.0.26 * tomcat-util-scan-8.0.26
 
 
 *Exception Message:* javax.servlet.ServletException: Servlet
 execution threw an exception
 
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
 
 *root cause*
 
 java.lang.NoClassDefFoundError: org/apache/tools/ant/Task 
 java.lang.ClassLoader.defineClass1(Native Method) 
 java.lang.ClassLoader.defineClass(ClassLoader.java:760) 
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142
>>> )
 
 
>>> java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
 java.net.URLClassLoader.access$100(URLClassLoader.java:73) 
 java.net.URLClassLoader$1.run(URLClassLoader.java:368)
 
 
 // Exception is thrown when trying to instantiate DeployTask
 
 DeployTask oTask = new DeployTask(); oTask.setAlwaysLog(true); 
 oTask.setAppend(false); oTask.setCreateEmptyFiles(true); 
 oTask.setError(oTaskError); oTask.setFailonerror(true); 
 oTask.setLogError(true); oTask.setOutput(oTaskOutput); 
 oTask.setPassword("adminManagerScript"); oTask.setPath("/broker"); 
 oTask.setProject(new Project()); oTask.setTag("v7"); 
 oTask.setUpdate(true); 
 oTask.setUrl("http://localhost:8080/manager/text";); 
 oTask.setUsername("adminManagerScript"); 
 oTask.setWar("/Users/amitlonkar/Documents/Builds/2015-09-23_1612/v7bro
>>> ker.war");
 
 
>>> oTask.execute();
>>> 
>>> This application works on a clean, fresh Tomcat 7 but not on a clean,
>>> fresh Tomcat 8?
>>> 
>>> - -chris
>>> -BEGIN PGP SIGNATURE-
>>> Comment: GPGTools - http://gpgtools.org
>>> 
>>> iQIcBAEBCAAGBQJWBbL0AAoJEBzwKT+lPKRYPaoP/jZywxrZGTFpXZunqTXO6lPi
>>> iU/Cg8KGql1/dxK8rs/SINKiJFpk9nsVkOf3596NKjLtHsD5vobzWwvnQyitnI1q
>>> WXjGX5PgIArZgBvbZOpEDZJpNOPCcJdXisZvhL5cO9qZBY/Pas/98KXKPZgD3LuB
>>> iMK+lns68CjrzYIRQEGsLBWSRMZSq5Mlo0QQkeD+bHJ/hhKSvAd/Fq+KhPuPxhnm
>>> 7YxX9VijsMBOWFtlMzn6+8KSOqvnKNTPV/VUzi5+5zHGWxA5JcEUsJlSP4CXpTRn
>>> HpoPW7d7MnqbHWIJRa6A5jmNe2Dgu/Yqnn0jP/DZ3vldPEkGzsrPK6TEEZ40Av8a
>>> HSrRpBTfO0YnPhrJJoDTbLHYwDxdt0+Pn7IN7fejdZtBfGHAZe2pvpys27Tc2yni
>>> 3IkrBY60TZZAmoShd+Db9nft8aAhJtFYpVuewZYpQBovKv9xNmRkuwzTQ1bDxqAc
>>> a/0wS9d2P4QARYToTD7X8I92Ve7KpTITXrKL6CHTKuzQxGIjpuD4fq/S+Niz2s9X
>>> zkfGE3HNhklaKZejeBvI34u3UvlyFZERpc3Ghz79NgbH6t+axl2DK8dUxqY8PXbQ
>>> UclOeihby91Fa5n5sP00LiGOJq9Pq8CFryYp5THbuMbUYZt3uxS53jiBQV2Wcy8q
>>> vysGmaX3rQK250gUVnj3
>>> =annF
>>> -END PGP SIGNATURE-
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.or

Re: Class Loader Problems with Tomcat 8 + Ant Task

[Christopher Schultz]

Amit,

On 10/16/15 3:44 PM, Amit Lonkar wrote:
> Thanks Chris
> 
> Tried two scenarios
> 
> 1. Removed any tomcat-*.jar files from webapp/WEB-INF/lib folder. Also moved 
> ant-1.9.6.jar from webapp/WEB-INF/lib to catalina/lib. All works fine now.
> 
> 2. Removed any tomcat-*.jar files from webapp/WEB-INF/lib folder, but this 
> time left the  ant-1.9.6.jar in webapp/WEB-INF/lib. Got the following error. 
> Since Ant is not shipped with tomcat we are bundling it with our application. 
> Any reason why Ant needs to be in tomcat/lib folder?
> 
> type Exception report
> 
> message Servlet execution threw an exception
> 
> description The server encountered an internal error that prevented it from 
> fulfilling this request.
> 
> exception
> 
> javax.servlet.ServletException: Servlet execution threw an exception
>   org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> root cause
> 
> java.lang.NoClassDefFoundError: org/apache/tools/ant/Task
>   java.lang.ClassLoader.defineClass1(Native Method)
>   java.lang.ClassLoader.defineClass(ClassLoader.java:760)
>   java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
>   java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
>   java.net.URLClassLoader.access$100(URLClassLoader.java:73)
>   java.net.URLClassLoader$1.run(URLClassLoader.java:368)
>   java.net.URLClassLoader$1.run(URLClassLoader.java:362)

It's all going to come down to which ClassLoader is in effect then the
thread tries to load that class. Was that the full stack trace? That
looks like an anonymous permission-executor class to elevate privileges
for a certain operation.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question for posgresq, and jdbc.jar placement.

[Ognjen Blagojevic]

Jose & Chris,

On 21.10.2015 20:47, Christopher Schultz wrote:

Jose,

On 10/21/15 7:33 AM, Jose María Zaragoza wrote:

IMHO

$CATALINA_HOME/lib  would be the right place


+1


Are you willing to elaborate why do you prefer $CATALINA_HOME instead of 
$CATALINA_BASE?


I don't have multiple Tomcat instances running, but I still split 
$CATALINA_HOME and $CATALINA_BASE to different directories in order to 
make Tomcat upgrades easier. Everything that is different from original 
installation goes to $CATALINA_BASE (bin/setenv.sh, conf/*, logs, 
webapp, etc... as well as additional jars including lib/(jdbc).jar. Thus 
when I upgrade Tomcat and change $CATALINA_HOME I don't have to think 
about additional jars.


-Ognjen

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

WebSocket permessage-deflate on tomcat7

[Artem Stsefanenko]

I have a web application which use web sockets.

I have tomcat 7.0.64 and tomcat 8.0.26. They both implements jsr 356 and
permessage-deflate (as I found from changelogs).

When I deploy war file to tomcat8 permessage-deflate works fine, but when I
deploy the same war on tomcat 7 permessage-defalte doesn't work. What may
be the cause?

The only difference which I found beetween tomcat 7 and tomcat 8 that
tomcat 8 use nio by default, but tomcat 7 bio connector. I tried to switch
tomcat 7 to nio connector only. But it doesn't work too.

I can't update to tomcat 8 by many reasons, so I have to configure it with
tomcat 7.

P.S. I use java 8u45.

Re: httpd 2.2 +mod-jk1.2.37+ tomcat 7.0.28 (debian package)

[tomcat]

On 21.10.2015 19:47, André Warnier (tomcat) wrote:

On 20.10.2015 00:13, J Lopez wrote:

Hi all,

   is it possible to filter 404 application errors taking into account
content-type beside http return code in jk configuration.
   I need to difference between application is not deployed/executing (http
404 content-type html) and application running and returning a 404 json
response (content-type json)

   I have put mod-jk in debug mode and content-type is showed in logs. I
have not seen in documentation if a fail_on_status can be combined with
content-type returned.


[...]

I have not seen this in the documentation either, and it does not look like 
this feature
is available.

But if I understand correctly, you have 2 cases of 404 :

1) if the application is for Tomcat "not there" (meaning for example it is not 
deployed at
that particular moment), then Tomcat itself returns a 404.
2) if the application is there and working, in some cases it returns a 404 
itself.

And for some reason, you want to distinguish these 2 cases.

(It would help to know why, and at what level you want to distinguish this)

But let's suppose that the application is normally installed at 
(tomcat)/webapps/app1, and
responds to URLs like "/app1/*".

If the "/webapps/app1" application is not there, then Tomcat will try to map 
this to the
default application, "/webapps/ROOT/app1/*".  Then it will probably not find it 
there
either, and return a 404 response.

If the application is there, then Tomcat will (succesfully) map the call to
/webapps/app1/*", and the application will respond. And, maybe, it will 
sometimes respond
with a 404.

So two possible solutions :
1) change the application, so that in such a case, it responds with something 
else than 404.
2) install something in /ROOT, which will catch everything that gets there, and 
respond
with something else than 404.
That supposes of course that you do not previously have a default application 
under
/webapps/ROOT.




Addendum :
The above suggests a (possible) way to do this at the Tomcat level.
But you also mention "mod_jk", which implies that you have Apache httpd acting as a 
front-end to Tomcat and this application.


You could also do this at the Apache httpd level.
For Apache httpd, mod_jk (and all that is behind it, but that Apache httpd does not know 
or care about) is seen as the "application", which generates the HTTP response.
To filter such a response and possibly modify it before it goes back to the client, you 
would have to use an "output filter" at the Apache httpd level.

Start from here : http://httpd.apache.org/docs/2.2/filter.html

But again, you did not really indicate the level at which you need this, or for what 
ultimate purpose, so it is not easy to recommend a "better" solution.




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: CsrfPreventionFilter for REST

[Violeta Georgieva]

Hi,

2015-09-17 10:55 GMT+03:00 Christoph Nenning :
>
> Violeta,
>
>
>
> > > > Hello,
> > > >
> > > > ** **
> > > >
> > > > *Background information:*
> > > >
> > > > We are trying to protect our RESTful
> > > > APIs
> > > > from
> > > > CSRF attack.
> > > >
> > > > The current Tomcat’s CSRF protection filter provides proper
> protection
> > for
> > > > web resources that are supposed to be accessed via some sort of
> > navigation
> > > > i.e. there’s an entry point which points to them (for example
> include
> > > > links/post forms to them) . With REST APIs you do not have such
> entry
> > > > points as the requests are done independently from each other.  We
> are
> > > > interested do you consider supporting  CSRF protection for RESTful
> > APIs?
> > > >
> > > > ** **
> > > >
> > > > *Example attack:*
> > > >
> > > > Here is an example how to reproduce CSRF attack of RESTful APIs
> using
> > the
> > > > attached apps:
> > > >
> > > >
> > > >1. Check customers initial state:
> > > >http://localhost:8080/restDemo/services/customers/  + login with
> > > >tomcat/tomcat
> > > >2.  **In the same browser open attacker’s app:
> > > >http://localhost:8080/XSRFAttackerApp/
> > > >
> > > > **
> > > >
> > > > Behind the scenes request 2. takes advantage of your credentials
> stored
> > in
> > > > the browser and makes attacking POST request to a state changing
> > operation
> > > > http://localhost:8080/restDemo/services/customers/removeFirst on
> your
> > > > behalf. After that the customer list is empty.
> > > >
> > > > ** **
> > > >
> > > > The problem is that if we use the CSRF filter to protect this API
> > > > /services/customers/removeFirst, this URL is then always served with
> > *403
> > > > Forbidden* (due to the missing csrf token).  In fact  the REST API
> > becomes
> > > > unusable.
> > > >
> > > > ** **
> > > >
> > > > *Research:*
> > > >
> > > > We’ve made some research on the topic and it seems that there is no
> > > > absolutely secure and at the same time clear stateless solution.
> Since
> > it
> > > > is possible for an attacker to insert  custom headers in the
> attacking
> > > > requests, the validation over header presence is not secure
> enough.
> > > >
> > >
> > > The ability to insert headers (or tokens in the request string as
> > > Tomcat's CSRF filter requires) is irrelevant, because  the attacker
> > > has to know the exact token value and the value is random.
> > >
> > > If you are constantly receiving 403 on your POST requests it means
> > > that you are requesting wrong URL (one that does not contain the CSRF
> > > token) or your requests are not a part of the session.
> > >
> > >
> > > > The only stable solution is again based on Synchronizer Token
> > > > Pattern<
> > https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%
> > 29_Prevention_Cheat_Sheet
> > >
> > > > but
> > > > instead of encoded in URLs, the csrf token value can be transferred
> from
> > > > and to the client through a custom csrf token header.  The rest csrf
> >  token
> > > > value needs to be stored in some sort of state on client and server
> > side.
> > > > In addition REST clients need to adopt this csrf token transfer
> > mechanism.**
> > > > **
> > > >
> > > > *Proposal:*
> > > >
> > > > You can find on the link
> > > > https://docs.google.com/open?id=0B-HUwAvkRIKJTVViWUFkNFl6alU , the
> > > > CsrfPreventionFilter extended so that it is able to successfully
> protect
> > > > state changing REST requests. They are validated based on the
> > > > “X-CSRF-Token” header (the header name is configurable).
> > > >
> > > > (...)
> > > >
> > >
> > > The main task of Tomcat's CSRFProtectionFilter is to protect the
> > > Manager application. The application does not use XMLHttpRequest so it
> > > cannot set the headers.
> > > So I see no point in implementing support for passing the token value
> > > in a header, as there is no use for it. Is there enough API available
> > > to extend the filter in a subclass to cover your specific use case?
> >
> > I would like to know whether there is an interest for such filter as
> part
> > of the filters that Tomcat provides by default to its users.
> >
>
>
> Yes, it would be very interesting if tomcat would provide such a filter!

You can take a look at the sources in trunk.

Regards,
Violeta

>
> Regards,
> Christoph
>
>
>
>
>
>
>
> > Thanks and Regards,
> > Violeta
> >
> > > Note that CSRF protection has some specific task. It would not protect
> > > you if an attacker is able to request the "welcome" page and parse it
> > > to extract the token. It would not protect you if you are using
> > > non-secured HTTP and an attacker is able to sniff network traffic.
> > >
> > > Best regards,
> > > Konstantin Kolinko
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

Re: SSL and Virtual Hosting

[Björn Raupach]

Hi Chris,

thank you very much for the elaborate answer!

> On 21 Oct 2015, at 21:44, Christopher Schultz  
> wrote:
> 
> Björn,
> 
> On 10/21/15 2:47 PM, Björn Raupach wrote:
>>> On 21 Oct 2015, at 20:42, Mark Thomas  wrote:
>>> 
>>> On 21/10/2015 16:27, Björn Raupach wrote:
 Dear group,
 
 it would be nice if anyone knows, if my planned setup is going to work.
 
 At the moment we are having two services (web apps) at two different 
 machines and hostnames. Lets say bob.example.com and alice.example.com 
 
 bob.example.com runs without SSL and deploys the web app at the root 
 context. We just throw a ROOT.war in /webapps.
 
 alice.example.com needs SSL at all times. It currently does not run with 
 the root context but we would like to. So another ROOT.war. We have an SSL 
 cert for alice.example.com
 
 I want both applications to run on a single Tomcat instance with Virtual 
 Hosting. Virtual Hosting with Tomcat that is. I am comfortable with 
 setting up Virtual Hosting, but I am just not sure about the SSL part. 
 Does the choice between IP-based or Hostname matter? bob.example.com might 
 need SSL support in the future.
 
 We are using Amazon AWS if that is important. So I could get another 
 Elastic IP. We are working with the latest Apache Tomcat 8 and the latest 
 JDK on the server machines.
 
 Sorry if this is not 100% Tomcat related.
>>> 
>>> Currently it will work if both hosts can share the same certificate
>>> because they share a connector and (currently) a connector can only have
>>> a single certificate.
>> 
>> How can both hosts share the same certificate?
> 
> I think he meant that if both sites "can" share a certificate, the whole
> thing becomes easier. For example, a certificate with a
> subject-alternative-name, or a wildcard certificate.
> 
> Recent versions of Java support SNI which should allow multiple
> certificates to be used, but I'm not sure if Tomcat supports that
> directly right now (see Mark's comments about multi-certificate support
> in the very near future).
> 
>> Do I need a SAN certificate or can I just run with the cert for
>> alice.example.com  and have to live with any
>> cert errors on bob.example.com ?
> 
> Well, those are both options, but the first one costs a heap of money
> and the second is unpalatable for users (errors = bad).
> 
>>> As of 9.0.x (and hopefully eventually back-ported to 8.x) you'll be able
>>> to have per host certs. There should be a 9.0.0-RC1 in the next week or so.
> 
> This is the "holy grail" of TLS certificate support -- one that I hope
> will be able to be back-ported without too much pain for (probably) Mark.
> 
> IIRC, this will also allow *either* PEM-file-based setup *or*
> keystore-based setup regardless of the crypto implementation (OpenSSL
> vs. JSSE) being used. I personally detest keystores because they are so
> fault-intolerant, but they do have the advantage of being able to say
> "use any matching certificate in this blob" to get work done.
> 
> So... if you are willing to wait a bit (9.0-RC1 in the next week? woah!)
> for a back-port from trunk into the 8.0.x branch, then that's probably
> your best bet. If you absolutely need to get this out right away, I see
> only a few options:
> 
> 1. Wildcard cert
> 2. Cert with a SAN
> 3. Front each service with AWS ELB
> 4. Front both services with httpd, which supports SNI
> 5. Use two s, each on a different port
> 6. Use two s, each on a different interface
> 
> That last one (6) might not be possible on AWS, since the host is itself
> mostly unaware of the public IP address external clients use to access
> it. (I have an EC2 instance with both internal and external IPs, and I
> only have "lo" and "eth0" interfaces, so I couldn't bind a 
> to the public IP's interface).
> 
> Option #3 might be the best for you in the short-term (and possibly the
> long-term), because it allows you to easily configure TLS *and*
> port-redirection without the complexity of a whole server+httpd instance
> to maintain. It will also allow you to grow your service trivially in
> the future should you choose to do so. The downside is that you pay for
> the ELB by the bit-transferred. It's up to you to decide how much you're
> willing to pay for that kind of thing.

I go with your option #3. AWS ELB is new to me but I have a look. In the
end it is probably cheaper than paying another EC2 instance. 

And if Tomcat 9 and eventually Tomcat 8 with SNI arrives, I can ditch 
ELB.

> 
> Hope that helps,
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional com