Re: Tomcat 9 doesn't shutdown cleanly

2021-11-30 Thread Terence M. Bandoian

On 11/30/2021 8:40 AM, Simon Matter wrote:

Hi Chris,

Thank you for the quick reply.


Simon,

On 11/30/21 08:21, Simon Matter wrote:

I'm running an application on Tomcat 9.0.55 on x86_64 Linux with OpenJDK
JRE-11.0.13+8 and have problems shutting down Tomcat in certain ways.

When I shutdown Tomcat via 'catalina.sh stop', it shuts down mostly
(most
threads are gone) but send a thread dump to catalina.out and is later
killer by an OS signal.

This should only happen if you have CATALINA_PID defined. Are you indeed
defining that environment variable?

catalina.sh has this code in it, which is probably what you are seeing:

echo "To aid diagnostics a thread dump has been written to
standard out."
kill -3 `cat "$CATALINA_PID"`


That's true, I have CATALINA_PID defined when the call of "catalina.sh
start" is done. So yes, the script will kill the java process if it
doesn't terminate.


When shutting down Tomcat via the shutdown listener on port 8005, it
also
shuts down mostly but without the thread dump in catalina.out. Sending
SIGTERM later to the still running java process terminates it.

Right: when you manually connect to the shutdown port and send
"SHUTDOWN" (or whatever), it asks Tomcat to shut down but doesn't send a
signal. You have to do that manually, too.

On a test host, when I send "SHUTDOWN" to the shutdown listener, Tomcat
shuts down and the Java VM terminates.

Only on this host with the application, when I send "SHUTDOWN" to the
shutdown listener, Tomcat shuts down but the Java VM doesn't terminate.


So both methods somehow terminate Tomcat partly but not completely.

You have one or two of the following issues:

1. You have a non-daemon thread running
2. You have an unusually long shutdown process that just takes "too long"

The good news is that the thread-dup can answer that question: what's in
the thread dump that is generated when you run "catalina.sh stop"?


When simply sending SIGTERM on the OS level, Tomcat shuts down cleanly
and
terminates without issues.

One thing in common is that I always see these messages while shutting
down:

30-Nov-2021 13:59:36.985 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:2071](local),objID:[0:0:0, 0]. This RMI
Target has been forcibly removed to prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class [com.sun.proxy.$Proxy51] and
value
[Proxy[ShopdbCacheSynchronizer,RemoteObjectInvocationHandler[UnicastRef
[liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[-6f4b2f9d:17d70eb1ef4:-7ffd,
-4005526521234186948]]. This RMI Target has been forcibly removed to
prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[0:0:0, 0]. This RMI
Target has been forcibly removed to prevent a memory leak.

Why do the three methods to shutdown Tomcat differ and how can I make
'catalina.sh stop' or the shutdown listener work the same way like
sending
the OS signal.

What's the difference? You don't want the thread dump in your
catalina.out? That's supposed to be helpful in debugging why your
shutdown isn't clean. It sounds like you are saying "help me with my
unclean shutdown; please get rid of the debugging information that is
trying to help me!".


I've tried, beside a lot of other things, to set
skipMemoryLeakChecksOnJvmShutdown="true" in context.xml but it seems to
change nothing at all.

Tomcat will never kill your non-daemon thread(s) from inside the VM.
Since you are using a CATALINA_PID environment variable (and, therefore,
a pid-file), the shutdown process is sending the TERM signal. It's also
possibly sending a KILL signal, depending on whether or not the TERM
worked and if -force was supplied on the command-line.

Unfortunately I am not an insider when it comes to Java, so I'm not sure
what a non-daemon thread means here? Can these be threads started by our
application which are non-daemon threads? So they will be terminated with
SIGTERM to the Java VM but not using the shutdown listener?

I'll paste a thread dump below.

Thanks,
Simon

Full thread dump OpenJDK 64-Bit Server VM (11.0.13+8 mixed mode):

Threads class SMR info:
_java_thread_list=0x55a49ac4ba60, length=18, elements={
0x7f1ac0148800, 0x7f1ac014a800, 0x7f1ac015f800,
0x7f1ac0161800,
0x7f1ac0164000, 0x7f1ac0168800, 0x7f1ac016a000,
0x7f1ac01ad800,
0x7f1ac0258000, 0x7f1ac0311000, 0x7f1ac0318000,
0x7f1ac031a000,
0x7f1ac25d6800, 0x7f1ac25fe800, 

Re: Timestamp Error

2021-08-27 Thread Terence M. Bandoian

On 8/27/2021 2:31 PM, Jerry Malcolm wrote:


On 8/27/2021 1:30 PM, Mark Eggers wrote:

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data 
truncation: Incorrect datetime value: '1969-12-31 18:00:00.0' for 
column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into 
phpMyAdmin, and it worked.  When I change the date to '2021-08-27 
01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016. But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right 
now,
I don't know what dates are going to work and what dates are 
going to fail.


Am I missing something obvious?  I've never had a SQL statement 
that failed consistently on TC but worked when pasted into 
phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that 
your system is running in Us-Mountain Time, 6 hours behind UTC in 
the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, 
and that your driver is using MDT as your time zone, trying to 
convert NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT 
-> boom, since the minimum allowed TIMESTAMP value is 1970-01-01 
00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't 
good for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my 
dev machine.  However, my production server (Linux) does have the 
timezones all set correctly.  My insert statement has a value of 
"new Timestamp(0).toString()".  On the production server, this 
becomes '1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value? mySQL 
accepts 1969-12-31 18:00:00.0 in the insert statement. mySQL may be 
adjusting the time +6 on my laptop back up the epoch value before 
storing it.  But the situation still remains that the same insert 
statement works on phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 
00:00:00.0' in the insert statement, but works with that value when 
inserted into mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  
Is the driver detecting this and generating the exception?  Or does 
the insert statement get all the way to mySQL and mySQL fails back 
to the driver followed by the driver throwing the exception?


Jerry


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



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/

|Timestamp 
(long time)| 


Constructs a |Timestamp| object using a milliseconds time value.
|time| - milliseconds since January 1, 1970, 00:00:00 GMT. A negative 
number is the number of milliseconds before January 1, 1970, 00:00:00 
GMT.


This says that a timestamp can be before the epoch, no minimum time, 
which agrees with what I'm seeing via phpMyAdmin.  Which means that 
what I'm providing in the sql insert statement should be accepted 
regardless of timezone factors. Seems to me there's a bug in the TC 
driver (??)  And the error message I'm getting says "data truncation", 
which at best is incorrect wording.  Not sure how any truncation could 
occur on a date string that parses to (long)0.  I thought the .0 
fractions of a second on the end of the string could be the cause of 

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-26 Thread Terence M. Bandoian

On 8/26/2020 11:27 PM, Pratik Shrestha wrote:

Dear all,

Thanks for so many replies and your discussions.

For me, there are two options for the fix which I am not able  to make them
work.

1. Either show 'ERR_EMPTY_RESP' like old Tomcat version 7 used to show. As
far as I know, with Tomcat 7 giving that error, Qualys did not use to show
this vulnerability.
2. *Best is to do a redirect* when Tomcat sees error 400 to https URL. Like
in Apache, we can add below.
'ErrorDocument 400 "*https*://xxx.xxx.xxx.xxx"
But as understood, redirect only works with error 3XX and ErrorDocument
feature is not there in Tomcat yet.

@Jon, yes, what we want is redirect on error 400 (explained in #2 above).
And please ignore port 9443.

Regards,
Pratik


With HTTPD rewrite, whether or not the request is encrypted or sent to 
the correct port can be detected and the request redirected as 
appropriate. Maybe the same can be done with the rewrite valve used with 
Tomcat.


-Terence Bandoian


On Thu, Aug 27, 2020 at 3:16 AM 
wrote:


What is the URL they are testing? Is there a reason there is a 9443 port
open? How about adding a blank page with a redirect, or use the rewrite
valve to rewrite to https?


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message. Thank you for your cooperation.


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, August 26, 2020 2:56 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by
Qualys

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 13:59, Mark Thomas wrote:

On 26/08/2020 17:50, Christopher Schultz wrote:

On 8/26/20 05:27, Mark Thomas wrote:

On 26/08/2020 08:14, Martin Grigorov wrote:

Hi,

On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha
 wrote:


Thanks for reply,

Hi Peter - it complains on port 8443 which belongs to Tomcat.

Hi Mark - Yes. making HTTP request on HTTPS is wrong. But this
security vulnerability is given to us by Qualys scan.
It tries to post plain HTTP request on HTTPS port and then gets
error message "Bad Request. This combination of host and port
requires TLS." which is security loop hole for Qualys.

On what basis?
I fail to see any security issue here other than "Qualys says so"
which is not a valid description of a security vulnerability.

My guess is that this is some form of "server fingerprinting"
that they are claiming, like "Zomg! It says Server:
Apache-Coyote/1.1! You are $uper vulnerable to 0days, now!".

The entire response, including headers is,

= HTTP/1.1 400 Content-Type: text/plain;charset=UTF-8
Connection: close

Bad Request This combination of host and port requires TLS. =


Pratik, can you please be very clear about what the actual complaint
is? Are they objecting to one or more of the
following:

0. Any legible response at all (meaning they just want a
connection-drop response) 1. Server: Apache-Coyote/1.1 response
header 2. Predictable / stock text (e.g. "Bad Request. This
combination of host and port requires TLS." identifies the server as
Tomcat v.x.y or later) 3. Actual Tomcat version number in response


Absent a description of how this can be exploited (and I'll be very
surprised if this can be exploited), there is no security issue here
and Tomcat will not be making any changes.

It seems reasonable to (configurably) strip-out version information
if there is anything in there... which there probably is not.

Correct, there isn't.


I'm interested in having Tomcat be able to pass these (admittedly
stupid) security requirements,

I have no interest in adding bloat to Tomcat so it can pass so called
security requirements that have no relevance to actual security. Those
sort of changes are the sort that get me starting to think about using
a veto.

Understood. But what does the OP have in terms of options at this point?

1. Ignore the complaint (probably not possible) 2. Request a waiver for
this issue (probably not possible, or at least would require 10 years of
red tape) 3. Front the server with httpd + "ErrorDocument 400" (which ... I
think will *also* reply with a plaintext response, right?) 4. Switch to
Jetty

I'm trying to avoid "the easiest thing" which is probably to switch to
Jetty. I know our "customers" don't pay for Tomcat, but losing a "customer"
sucks.


so maybe we could have a setting on the  that can allow

Re: Dates on Linux vs. Windows

2020-01-08 Thread Terence M. Bandoian

On 1/7/2020 6:53 PM, Jerry Malcolm wrote:
>> If your systems always use the same time zone to read and write the 
data, it isn't a problem.


Terrance, thanks for the info.  In my case I do only have one timezone 
(or at least I want to...).  Using the string for dates is a good 
idea.  But this is a massive application that's been in production for 
years with tons of date and timestamp fields spread everywhere across 
the code and the db.  So converting to strings is not a possibility now.


It still comes down to the fact that the mysql command line on my 
linux box gets the date right, but it's converted incorrectly by JDBC 
and only on the linux box (and works on WIndows)


When I first set up the box an installed Tomcat, the default Linux 
time was gmt.  I didn't change the Linux time to central until later.  
Any chance that tomcat stored the timezone in effect when it was 
installed and still is using that even though I changed the linux 
timezone?  (Just grasping at straws here).





Hi, Jerry-

I realize you've found an apparent work-around for the issue but, to be 
clear, I did not use character columns.  The column types were 
DATETIME.  However, when I inserted or updated, I provided string values 
(e.g. update MyTable set myDateTime = '2020-01-08 06:57:00').  And, when 
I read the data, I extracted date/time values from the result set using 
getString (e.g. parseSqlDateTime( resultSet.getString( "myDateTime" ) ).


Best regards.

-Terence Bandoian

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



Re: Dates on Linux vs. Windows

2020-01-07 Thread Terence M. Bandoian

On 1/7/2020 4:04 PM, Zahid Rahman wrote:

  Jerry Malcolm wrote :

  >Again this is the SAME line of code in java reading the   >SAME field in

the SAME database.  Only thing different is  >Linux/Windows OS




On Tue, 7 Jan 2020, 21:52 ,  wrote:


-Original Message-
From: Jerry Malcolm 
Sent: Tuesday, January 07, 2020 3:14 PM
To: users@tomcat.apache.org
Subject: Re: Dates on Linux vs. Windows

On 1/7/2020 3:09 PM, Michael Osipov wrote:

Am 2020-01-07 um 21:58 schrieb Jerry Malcolm:

This may be more of a Java question than Tomcat.  But I'm not sure. I
have the same code, talking to the same MySql Linux (AWS) database.
I read a date column value in a Tomcat app.  After calling
resultSet.getDate(...) I printed the date instance and the getTime()
value:

On windows: 2019-02-01 154900080

On linux:   2019-01-31 154897920

Again this is the SAME line of code in java reading the SAME field in
the SAME database.  Only thing different is Linux/Windows OS.  The
date is supposed to be 2/1/2019 and shows that in phpMyAdmin.

I've been running on Linux for a few months.  But I don't have an
extensive background in the specifics of Linux.  I'm sure there must
be something that is configured differently.  I'm at a loss. But this
is not a trivial problem.  I do monthly billing. My dates need to be
accurate.

Have you verified that you aren't tricked by any timezone issues?

Probably so.  But how would I know?  I was under the impression that
java.sql.Date was timezone independent.  Shouldn't it simply convert a
month/day/year value to the number of milliseconds since the epoch?  How
would timezone issues affect that?  And if I am 'tricked' how do I
'untrick'.  What do I set/change?



Those millisecond values are 6 hours apart, which looks like a timezone
issue.  I happen to be in US Central time, which is 6 hours earlier than
UTC in winter.

You're right that System.currentTimeMillis() itself is independent of
timezone but Date is not.


As I understand it, for certain date/time column types, MySQL subtracts 
the time zone from the value when written and adds it back in when 
read.  If your systems always use the same time zone to read and write 
the data, it isn't a problem.  But it can be if the time zone varies.


See https://dev.mysql.com/doc/refman/5.7/en/datetime.html

The actual behavior is a little confusing, at least to me, because I 
seem to remember variations in the storage of the date/time columns 
while the documentation seems to indicate that date/time values are not 
modified.  Also, if I remember correctly, writing a date/time value as a 
formatted string and then reading it back as a string (e.g. 
ResultSet.getString) and parsing it circumvented the time zone issue.


Hope that helps.

-Terence Bandoian


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



Re: Initiating httpservletrequest from inside Tomcat / TomEE

2019-05-06 Thread Terence M. Bandoian

On 5/6/2019 10:45 AM, Paul Carter-Brown wrote:

Yea, but the issue is that only works when calling in the context of a
current servlet call.

Here is the kind of problem I want to solve:

@WebServlet(name = "MyExample", urlPatterns = {"/example"}, loadOnStartup =
1)
public class Example extends HttpServlet {

 @PersistenceContext
 private EntityManager em;

 @Override
 public void init(ServletConfig config) {
 Thread t = new Thread(() -> {
 while (true) {
 try {
 // Do a GET to /example/ and get the response without
going out on localhost and back in
 // We cant just call doGet as we want the request to
flow through the servlet filters, do the entitymanager injection etc
 Thread.sleep(1);
 } catch (Exception e) {
 }
 }
 });
 t.start();

 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
 // do stuff like use em
 resp.setStatus(200);
 resp.getWriter().write("Hello World");
 }

}




If I understand the problem you're trying to solve, it seems like there 
could be two ways to approach it.


1) Can your service be initialized with the context information it needs 
to use the request dispatcher?
2) Can the servlets you want to use be refactored so that the underlying 
functionality is exposed in a way that doesn't require any context?


Hope that helps.

-Terence





On Mon, May 6, 2019 at 5:35 PM John Dale  wrote:


For reference, I did find this after searching "calling a servlet
programmatically":
https://docs.oracle.com/cd/E19146-01/819-2634/abxbn/index.html

On 5/6/19, Paul Carter-Brown  wrote:

I think we are completely missing each other. Forget sockets - that was
just an example. I have code running in a Tomcat App server which is not
managed by Tomcat and is not initiated by anything within Tomcat. That

code

now wants to call a servlet hosted in that very same JVM. Any way to do
that without going out and back in on TCP?


On Mon, May 6, 2019 at 5:14 PM John Dale  wrote:


Sockets are an implementation of TCP/UDP inherently.

Perhaps a mountaintop signal fire?

;)

John


On 5/6/19, Paul Carter-Brown  wrote:

lol on the Semaphore Telegraph,

I can't use a request dispatcher as the request is being initiated

from

code that has no context. I already have it working with HTTP using
asynchttp library, but I want to avoid the overhead. E.g. lets say I

wrote

my own server socket listener on port 1 running in the Tomcat JVM
and
got some request in some propriatary protocol called X. Now I want to

call

a Tomcat servlet in the current JVM with some info I got over X

without

going out on TCP and back in

On Mon, May 6, 2019 at 4:40 PM John Dale  wrote:


If you're wanting to forward control to another servlet deployed in
the same context:
https://www.javatpoint.com/requestdispatcher-in-servlet

If you are okay going through TCP to facilitate some future or

current

distribution of services, Use HTTPURLConnection (not sure what you're
wanting to do with the result of the request, if anything):



https://stackoverflow.com/questions/2793150/how-to-use-java-net-urlconnection-to-fire-and-handle-http-requests

If you need more sophisticated HTTP interactions, Apache maintains a
very useful library for that:  http://hc.apache.org/

If these don't work-out for you, rather than using .NET, PHP, Python,
or some other Java facsimile at best, I recommend using the semaphore
telegraph:
https://en.wikipedia.org/wiki/Semaphore_telegraph

Sincerely,

John
DB2DOM

On 5/6/19, Paul Carter-Brown  wrote:

Hi John,

Thanks for your feedback.

The request I'm initiating should not or need not carry any context
from
the originating code. There is also no session to worry about as

its

just
for rest calls. So basically I have the headers, path and body and

need

to

generate a http servlet request and get an http servlet response

(or

similar) back. I have this working by calling into localhost but
ideally
want to skip the trombone out and back in.

Have you got any basic code examples?

Paul

On Tue, Apr 30, 2019 at 5:27 PM John Dale 

wrote:

Another thought .. you can do some request dispatching, but

without

knowing more about the tools you're using, I can't say for sure if
this is the direction you'll want to go.

On 4/29/19, Paul Carter-Brown 

wrote:

Hi

I'm trying to design a Kafka consumer and producer that will run

inside

the

tomcat jvm and pick up messages off a Kafka topic and translate

them

into a

servlet request and pass it through tomcat and then when the
response
is
complete then translate it into a Kafka message and put it onto

another

topic as a reply. This way I can reuse our existing jax-rs rest
services
and expose them as an async api over Kafka. The idea is to make
the
Kafka
messages 

Re: how to prevent user access to JSP pages?

2018-08-26 Thread Terence M. Bandoian

On 8/23/2018 4:26 AM, Mark Thomas wrote:

On 22/08/18 19:48, Terence M. Bandoian wrote:




Back on topic, do JSPs have to be registered with the container using
servlet mappings in web.xml or some other mechanism in order to serve as
targets of forwards by servlets?  Further, does doing so make those JSPs
accessible via external requests?  I suspect the answer to both
questions is yes which means an additional mechanism will have to be
introduced to block that access which I believe was the original
question.  Servlet filter?

What makes JSPs accessible is the mapping of *.jsp to the JSP servlet.
Any file outside of WEB-INF with a .jsp extension will be passed to the
JSP servlet for processing:
- .jsp -> .java
- .java -> .class (servlet)
- send request to servlet from previous step

JSPs (or any other files) located under WEB-INF are never directly
accessible.

Forwards and includes can reference JSP files (actually any files)
located under WEB-INF and the file is processed the same way it would be
if it were located outside of WEB-INF. The idea of locating files under
WEB-INF is so you can use them in forwards and includes without them
being directly accessible.

Mark

P.S. It is actually WEB-INF or META_INF everywhere I write WEB-INF above
but I only used WEB-INF to try and keep it clearer.



Thanks for clearing that up.  It's surprisingly simple.  The only 
complication I found is that a "NamedDispatcher" is required to forward 
to pre-compiled JSPs in WEB-INF that don't have servlet mappings.


-Terence Bandoian


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



Re: how to prevent user access to JSP pages?

2018-08-22 Thread Terence M. Bandoian

On 8/21/2018 11:44 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 8/20/18 1:31 PM, Berneburg, Cris J. - US wrote:

Hi Mark

Thanks for taking the time to reply.  :-)

cjb> Due to security concerns and general fussiness on my part, I'd
like cjb> to prevent users from requesting JSP pages directly
[...].  That cjb> way I can legitimately claim that all requests
are being validated, cjb> input scrubbed, JSP's cannot be taken
advantage of w/o their cjb> servlet chaperones being present, etc.

mt> I'm struggling to understand what risks exists with JSPs that
don't mt> with Servlets. After all, a JSP is just an alternative
way to write mt> a Servlet. Tomcat translates the .jsp file to the
.java source for a mt> servlet, compiles it and runs it. mt> Can
you elaborate?

See Chris Shultz's reply about MVC.  He pretty much nailed it.

For me, it's a twofold combination of (a) security concerns and (b)
separation of responsibilities.

a. Security - shrink the attack surface.

It's worth pointing-out that what's shrinking is the attack surface
*of the application*, not necessarily of JSP (as a technology) itself.
While I agree 100% with (a), here, it's not because there is anything
inherently risky about JSPs. It's that most people end up writing
really awful JSPs that are full of holes.


b. Separation of duties - I want the JSP's to simply render pages
and the non-JSP servlets to do all the heavy lifting.

This item (b) allows you to more effectively achieve (a) IMHO. Also,
"separation of concerns" allows you to focus on one task in one piece
of code, instead of having a JSP that needs to enforce security,
sanitize inputs, query a database, manage the result set, etc. all
while providing error-handling, etc. Anything that makes code more
maintainable is a big +1 in my book.

One of the ways I have kept my code as maintainable as possible is by
not using JSPs :)

- -chris



So, you don't like JSPs.  Okay by me.  Others have found them useful.

Back on topic, do JSPs have to be registered with the container using 
servlet mappings in web.xml or some other mechanism in order to serve as 
targets of forwards by servlets?  Further, does doing so make those JSPs 
accessible via external requests?  I suspect the answer to both 
questions is yes which means an additional mechanism will have to be 
introduced to block that access which I believe was the original 
question.  Servlet filter?


In some cases (e.g. GET requests), it may be simpler to perform any 
required validation in the JSP.


Also, shouldn't all JSPs be located in WEB-INF?  If I remember 
correctly, built-in protection is provided to prevent access to the 
source code of JSPs within WEB-INF.  In addition, I'd recommend 
pre-compiling JSPs when possible.


-Terence Bandoian



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



Re: how to prevent user access to JSP pages?

2018-08-18 Thread Terence M. Bandoian

On 8/17/2018 8:52 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/17/18 3:54 AM, Mark Thomas wrote:

On 16/08/18 18:19, Berneburg, Cris J. - US wrote:

Due to security concerns and general fussiness on my part, I'd
like to prevent users from requesting JSP pages directly, except
for the login page.  I want all requests to be handled by
servlets.  That way I can legitimately claim that all requests
are being validated, input scrubbed, JSP's cannot be taken
advantage of w/o their servlet chaperones being present, etc.

I'm struggling to understand what risks exists with JSPs that don't
with Servlets. After all, a JSP is just an alternative way to write
a Servlet. Tomcat translates the .jsp file to the .java source for
a servlet, compiles it and runs it.

Can you elaborate?

JSP support for input validation, etc. is basically non-existent. I'm
sure someone has a crappy library that can do it, and yes, you can
implement everything in JSP using miles of tag libraries and stuff
like that, but in the application world, that's a serious no-no.

MVC (or some version of it, under various names) is the "proper" way
to build software, and JSPs are relegated to the "V" portion of that
paradigm.

Once you have decided that JSPs are squarely in the "V" category, it's
no longer appropriate for them to be treated as "C" components and
therefore they should not be accessed directly. Protecting them from
direct-access is a reasonable decision for a number of reasons,
including security if you have pages that cough-up sensitive
information under the assumption that authentication and authorization
requirements have previously been satisfied.

Sure, the container's authentication and authorization should be able
to protect those JSPs just fine, but the application may have other
controls in place that also need to sanity-check things before the JSP
takes over.

So, while there isn't anything particularly "dangerous" about
direct-access to JSPs, there are a number of "best practices" that
suggest that hiding them is a good idea.

I hope that helps explain Cris's (likely) reasoning a little more.

- -chris



As far as I know, there is no input validation that can be performed in 
servlets that can't also be performed in JSP pages using the same Java 
code.  Also, I'm not aware of any functional limitation that prevents 
JSP pages (classes) from being used as controllers.  As I understand 
them, JSPs can do anything that can be done in servlets and offer 
additional facilities and ease-of-use.  They may be thought of as 
view-generators only but I don't think that's a functional limitation.


Could a servlet filter be used to reject external requests for JSP pages?

-Terence Bandoian


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



Re: Jsp pages with scriptlet and javadoc comments loaded in char[]

2018-05-02 Thread Terence M. Bandoian

On 5/2/2018 07:30, M. Manna wrote:

Hi Mark,

Basically, our application has quite a lot of large objects which are
singletons. When we checked the list of char[] objects loaded in the
memory, some of them showed JspServlet related Strings and had commented
code loaded into char[].
we have quite a lot of Strings loaded in memory (using maps) which are
necessary. heap-dump will always report this as a memleak but it's not - So
trying to understand whether we can utilise anything from tomcat side to
remove
I understand it sounds odd, but at that point it appeared to be something
we can just strip out. But from your comments, it doesn't seem to be an
option.

Thanks,



Pre-compiling the JSP pages might be worth consideration.

-Terence Bandoian



On 2 May 2018 at 10:39, Mark Thomas  wrote:


On 02/05/18 10:31, M. Manna wrote:

Hi All,

I had a specific question regarding JSPs loaded in web-application
container for jasper to compilation. If I have a JSP page which has
scriptlet and javadoc comments/code comments, aren't those loaded into

the

char[] of JSP pages too?

No.


I understand that Jasper compiles the JSPs but
those comments aren't stripped out (apologies if I have missed something

in

source code). I am using tomcat 8.5.28.

Yes, they are. HTML comments (which are essentially template text) are not.


In other words, by cutting down all javadoc comments/commented code from
JSP scriptlets, can I assume some savings will be made in terms of char[]
memory size when my servers are very busy? I have about ~3k JSP pages

with

a mixture of nice clean JSPs and really messy scriptlets. And I am trying
to find some options to tune GC and see if reducing char[] sizes can help
me in any way.

Seems like an odd way to tune GC. What problem are you trying to solve?

Mark

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






Re: Tomcat question

2018-04-24 Thread Terence M. Bandoian

On 4/23/2018 11:46 AM, zahi.f...@gmail.com wrote:

I used the “manager” role for basic auth. While testing the web service with 
postman, I entered my user name and password.
Yet, I got unauthorized message (401)..

I couldn’t find any explanation for this issue..



What do the log files say?

-Terence





On 23 Apr 2018, at 19:41, Christopher Schultz  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Zahi,


On 4/23/18 10:13 AM, zahi.f...@gmail.com wrote:
I just copied my users section in the tomcat-users. There is more
code - Tomcat users tag.. that shouldn’t be the problem cause I can
enter to the tomcat manager page

Well, if it shouldn't be a problem then why are you having a problem?

- -chris


On 23 Apr 2018, at 16:45, Christopher Schultz
 wrote:


Zahi,


On 4/23/18 9:38 AM, Zahi Fail wrote: I'm working with Tomcat
9.0.6 version as my servlet, Throughout my jax-rs project i
have tried to create basic authentication.

While i'm trying to access a post method without the basic
auth. it all working well (I got the 200 message from the
HTTP server). But, after adding the basic auth. my user name
and password doesn't work from some reason..


This is the following code from my web.xml file:

 http://www.w3.org/2001/XMLSchema-instance;
xmlns="http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd;
id="WebApp_ID" version="3.0"> User
Management  Jersey
RESTful Application
org.glassfish.jersey.servlet.ServletContainer
et-
class>





jersey.config.server.provider.packages
com.journaldev.jaxws.beans
  
Jersey RESTful Application
/rest/* 
 
simple web resource
/rest/Traffic/*
POST 
 manager
 
NONE
  
BASIC  



*and in the tomcat-user.xml i have updated the code as below:
*

  
  

Your tomcat-user.xml file is not a valid XML document.

-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


-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlreDLYACgkQHPApP6U8
pFhQJg/+MP//p9106wLrS3EG5aqkt6NpG4iZyL7btCRIb1iMQuhF0HGG/mSgtvWe
3/kyfAe81aiBxC6nfhEx9DepSAQ24/6nYLE5vEtInnKZelY7ehaH4/nDb6DVJMer
8C/onpnz7NValh+pecEj4mfhMoWc40poH+L4Ry1u8oiWzjjFW6g8QB37Ac759x7L
9GCHYK88z4fGFdDFSxVGsNMyy+FHgy3Dz+gJplAFXtIctTD7QC1Rk1Js+ioivj7F
6/fC9v0OoApqFAAKKDP/gsYhRP2KAFqgasFnLRU90ic8YLGtJ7GDayhi3EIEgNLz
GZIR1VwN0IqYDZ935Bxw1p/gRu6tgSgZS8MOF4jV64RST04p1LymEdmvcR7+N8HX
BYRJLYOChI2PjAfh7WmCHXSP8KK8hHA4bWKtuWB0XhLIvurHWE88x2ZwuqnabCAF
9Zh8XLpU7NLjTZGBVXYQPe0/xGVvElWSkVaX8TrIyVNY7qf9Nri+pgOLBdIz3AGy
COsoP3o9pMn8CkQPpA0Fq503sUU7GuMZByuGpyWayDxen1P4Gpv5o/YdDivUnJJ2
56NBksROXNVYHDT+mJox/6v7UNya5ssrEIquUtnEzr+3ZdChWtRXzglMPPUWVcdm
Ms5XDhKOUUKlHNynT7i+a3eeIOpn4UJZqJiBtp19IFPfN4XcSh4=
=ch87
-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



Question regarding running Tomcat 7.0.57 offline

2018-04-19 Thread Terence M. Bandoian

On 4/19/2018 12:37 PM, John Dale wrote:

Greetings;

I have a 2006 era macbook pro with the latest osx.

I run MySQL, which binds to localhost just fine when the network cable
is unplugged and wireless turned off.

Tomcat makes it through most of its startup, but hangs before
completion and requests from the browser hang and eventually timeout.

I've tried 127.0.0.1, 0.0.0.0, and omitted for the "address" attribute
of the connector.

With no network, Tomcat successfully makes a connection to MySQL to
creates the connection pool, but hangs.  There are no errors.

I am running debugging transport.

My hosts file is stock, fine.

As soon as I plug in a network cable or connect to wireless, the
server comes-up fine and I can access it on 127.0.0.1 or the static ip
assigned to either the wireless interface or the hard LAN.

I. am.  stumped.  Please help.  I need to be able to demo my project
without being connected to the network.

:\

I've been dealing with this issue for awhile, and I'm finally fed-up with it.

We want offline and we want it .. NOW! ;)

Thanks folks.

Sincerely,

John from Spearfish, SD



What do the Tomcat logs say?  Tomcat version?  JVM version?

-Terence


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



Re: Security of AJP

2018-03-01 Thread Terence M. Bandoian

On 2/28/2018 10:16 AM, Mark H. Wood wrote:

On Wed, Feb 28, 2018 at 09:25:53AM -0500, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chris,

On 2/28/18 8:40 AM, Cheltenham, Chris wrote:

Since AJP is not really needed by Tomcat; If I comment out the AJP
startup line in server.xml will that affect anything.

I still don’t even understand what its for. I have read the apache
docs but it doesn’t mean anything to me.. Apache's description
doesn't tell me anything.


The AJP Connector element represents a Connector component that
communicates with a web connector via the AJP protocol. This is
used for cases where you wish to invisibly integrate Tomcat into an
existing (or new) Apache installation, and you want Apache to
handle the static content contained in the web application, and/or
utilize Apache's SSL processing.

That is mumbo jumbo.

Is it?

Well, it could be improved.  For example, by using the
widely-understood word "proxy" somewhere, or defining "web connector".
Also by recalling that "Apache" is a huge array of various projects
(including Tomcat!), while "Apache HTTP Server" refers to a specific
web server daemon that can front-end Tomcat.  One could even link
"Apache HTTP Server" to 'http://httpd.apache.org/'.



+1.  Maybe "...communicates with an HTTP server via..." in the first 
sentence?  Also, the second sentence could be greatly simplified.


-Terence Bandoian


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



Re: _jspService is exceeding the 65535 bytes limit

2018-02-09 Thread Terence M. Bandoian

On 2/7/2018 4:37 PM, M. Manna wrote:

If this doesn’t cause pain, I would do the following:

1) Replace all in-body  scriptlets and use JSTL core tags in offending
JSPs. Most of the codebloats are caused by using intermediate scriptlets
e.g.

<% if (foo.bar() == jack.jill() ) { %>
// lots of jsp code
<%} else <%{ %>

2) use all your code in a stand-alone java class or lambda
Function/BiFunction. And call that using a single line to do all processing.

3) if you’re using ant for building, you can write a task utilising bcel
library to weigh the precompiled jsp sizes (65536b). But this is just a
recommendation.

I know I am asking for a refactor here. But this will help you a lot with
all the other option provided earlier. From 8.0.39 about 100 jsps in our
application broke because of The size. Just sharing our approach.

And BTW, don’t disable pooling, it won’t help that much.

Regards,



+1.  I'd suggest performing all data access and generating significant 
segments of dynamic output in separate classes and importing those 
classes into the JSP.


-Terence Bandoian
http://www.tmbsw.com/




On Wed, 7 Feb 2018 at 22:08, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jan,

On 2/7/18 3:13 PM, Mark Thomas wrote:

On 07/02/18 19:19, Jan Tosovsky wrote:

Dear All,

I've updated ancient tomcat to 8.0.49 and deployed app now throws
'65535 bytes limit' exception for certain JSPs.

Following this (older) thread
https://stackoverflow.com/questions/5484253/jspservice-is-exceeding-t

he-6553




5-bytes-limit I changed that mappedfile parameter, but it didn't help.

So I downgraded tomcat to 8.0.30 and it works fine again.

Should that mappedfile settings fix the issue so my observation
seems to be a regression in recent versions? Nobody complains
this solution doesn't work in that older thread.

It will help but it isn't a guaranteed fix. There are other
options.

You could try compilation with javac.

You could also try these settings: trimSpaces - true enablePooling
- false

Note the disabling pooling may impact performance. It depends on
lot on the complexity of the tags.

Also using jsp:include to split pages into separate parts should help.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlp7eM8dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgyVxAAqa1kWSJKv39DoR84
mZ+mW13VrNB/ruFdAAW/KF6QNVzSB7k0aFmesCpeX01ABKM1LVa6zK4HJa2Bng1+
bx5cNM4hZti/jvaIE7sfVRi6vtD15ArQ8gHWtH6Xa8GcC1+tehphyj0Ew6GIK+Xn
cvGe3V05Jl8gqYQiscJ33Jq9Xuseaslbvd0g6fJhStdB7i1TiDUvecd0TZqN9U2h
+OqAShvRBZvua/MnYfSF5T5Nl+UW7oSjfuVZWY0dPb7L1e9J4zHtwVP0QDdUzp6V
V6+CRrwbtKXZPYDmxtX5Vq9TVh6fqXfjiIi46AhQU3Ive5mc3UsuU1et/Mr4dRCu
x1fEhahrZuoKACCF5kAfJ12Ngbe6EeuXAjocBHzgyK6v9ZqkS+X1x9GNQtYU0bv0
PONoW4x34mLwtPd56pyAbyw2wkoq9fmM8Wi+3KcYG885bnDUG7Ud5+hop3MiExYe
J/cvip6CFsgdnJ1/xYcSk4b425ZucX2x2qPEVXOnQXbiJUxGTe7lpTtiwFAbotCI
SUyACeNoZHt7rovPh65ldt7G9F4LJjSmpaYQp+bLyRU8zuc89Oj514ZvgM2Y276E
DKEchsjD+fVFbBPCi95/A7RyZkIFubxXgWCrOfxuR0j4btu9cnTi1qhgOdoEZCyA
305EWpVOH04uFH6pl/ZAEsJyL4g=
=CB2q
-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



Re: Ajp Nio-thread stuck in loop and consuming a lot of cpu

2018-01-18 Thread Terence M. Bandoian

On 1/18/2018 7:45 AM, Rainer Jung wrote:

Just an addition to one of Mark's questions:

Am 17.01.2018 um 22:20 schrieb Mark Thomas:

Is it always the same threads generating the load or does it move
between threads?


Just in case Andreas is not aware: one can check with "top -H -p ".

Using -H lets top show one line per thread instead of one line per 
process. That way you can easily see CPU use per thread. The "-p 
" would simply filter to only show the threads in your java 
process (by using for  the process ID of your Tomcat java process).


Furthermore the PID column in "top -H" does not actually show the PID, 
but instead the thread IDs. If you convert that decimal numbers to 
hex, e.g. using the shell commandline


printf "0x%x\n" 

(and replacing  by the respective thread id of the lines that show 
high CPU usage), you get a hex number that will point you to the 
respective thread in the java thread dump by looking for tid=0x... in 
the thread header lines. The association between operating system 
thread number as shown in "top -H" and the tid in the Java thread dump 
does is stable during the lifetime of the process.


Regards,

Rainer




Thanks for posting this!

-Terence Bandoian
http://www.tmbsw.com/


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



RE: Tomcat SSL issue

2017-10-11 Thread Terence M. Bandoian

On 10/10/2017 9:45 AM, John Ellis wrote:


John Ellis

405.285.2500 office


 


http://biz-e.io


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Monday, October 9, 2017 4:49 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat SSL issue

On 10/9/2017 10:01 AM, John Ellis wrote:

I posted questions about this a couple of weeks ago I think it was. I
have been trying to get Tomcat running on a secure port with a valid
SSL certificate. We finally got version 9.0.0.M20 setup successfully
on port 9443 and I can go to that IP:port and get a Tomcat webpage but
when I go through all the steps using the keytool commands to submit a
certificate (we use Cacert.org) and try to plug that certificate into
the mix it doesn’t work. I still get an error message telling me that
I will have to create an exception to go to that IP address and port.
Last Friday I even deleted the certificate and all the keystore file,
etc. and got the same exact error. So it appears that Tomcat is not
seeing the certificate at all since I get the same error about having
to add an exception whether or not I have a valid certificate in place
on the server.

The lines we added to the server.xml file to get the secure port
working are-


keystoreFile=home/tomcat9.0.0.M20/apache-tomcat-9.0.0.M20/conf/keystore.jk
s"

keystorePass=hangeit" />

John Ellis

Thanks for the reply Terence. Yes I get the message about needing to create

a security exception when I first try to open the Tomcat webpage on the
secure port of 9443. I have deleted the certificate and supporting files off
of the server as I was going to start over with a new certificate. I believe
the error said something about not being able to verify the certificate. I
think the main issue is that this is just an internal server here in our
office running RHEL 6. It is not setup as a web server and it just has the
name of "cowboy" (given that name by my boss) so it is hard to figure out
what to call the "First and last name" part when I am creating the CSR to
send to Cacert.org. I can't just use the name "cowboy" as I don't have any
way to validate that. Have you ever run into situations like this? As I said
before I am not a programmer or developer or anything like that. My
background was in computer hardware for over 25 years until I took this
position after being laid off from what was formerly WebMD. We installed
systems in dr's offices, etc. Any light you could shed on this would be
great!
Thanks

Hi, John-

Is it a browser that's displaying the error message and requesting that you
create an exception to continue?  If so, have you looked at the additional
information to determine what problems the browser has detected with the
certificate?

-Terence Bandoian
   http://www.tmbsw.com/



Hi, John-

I would check the error message presented by the browser carefully and 
test with multiple browsers (e.g. Firefox, Chrome, IE, etc.). If you can 
copy the exact error messages to the list, someone might be able to 
offer more assistance.


If you're able to establish an encrypted connection, I would guess that 
Tomcat is at least finding "something" for a certificate.  And, you 
should be able to at least change the error message by altering your 
configuration.  If you can't, then something is amiss in the 
configuration process.  Was Tomcat restarted after the configuration was 
modified?  Is Java using a default location for the keystore? Is the 
keystore you specify in your Tomcat configuration modified when you 
execute the keytool commands?  Can you list the contents of the keystore?


If the browser can't verify the certificate, I'd guess that either 
intermediate certificates aren't available or the browser doesn't trust 
the certificate authority or the wrong address is used to access the 
server from the browser.  Detailed error messages would be helpful.


Instructions to generate a CSR are available on the Internet.  They vary 
though so you may have to dig to find something that works in your 
case.  I've found it best to use the instructions provided by the 
certificate provider.  In some cases, the prompt for first and last name 
is actually a request for the domain name to be secured. Also, a domain 
name that is at least recognized on your intranet will likely be 
required if you want to use a valid certificate.


It's been a while since I've configured Tomcat for SSL so I'm going on 
memory and can't offer much additional help.  There are others on the 
list though that probably can.  Specific details, such as Tomcat 
version, Java version and OS version and exact configuration, commands 
utilized and error messages make receiving that help more likely and 
more likely to result in success.


Hope that gets you started!

-Terence


-
To unsubscribe, e-mail: users-unsubscr...

Re: BREAKTHROUGH (but not solved) Re: Problem: (GSKit) No compatible cipher suite available between SSL end points.

2017-10-11 Thread Terence M. Bandoian

On 10/10/2017 1:20 AM, Peter Kreuser wrote:

Christopher,

A good read on the appropriate (openssl) cipher string that I use can be found 
here:
https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
Hynek explains the whys and don'ts and updates the string on a regular basis!

HTH

Peter



Nice article.  Thanks!

-Terence Bandoian
 http://www.tmbsw.com/


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



Re: Tomcat SSL issue

2017-10-09 Thread Terence M. Bandoian

On 10/9/2017 10:01 AM, John Ellis wrote:


I posted questions about this a couple of weeks ago I think it was. I 
have been trying to get Tomcat running on a secure port with a valid 
SSL certificate. We finally got version 9.0.0.M20 setup successfully 
on port 9443 and I can go to that IP:port and get a Tomcat webpage but 
when I go through all the steps using the keytool commands to submit a 
certificate (we use Cacert.org) and try to plug that certificate into 
the mix it doesn’t work. I still get an error message telling me that 
I will have to create an exception to go to that IP address and port. 
Last Friday I even deleted the certificate and all the keystore file, 
etc. and got the same exact error. So it appears that Tomcat is not 
seeing the certificate at all since I get the same error about having 
to add an exception whether or not I have a valid certificate in place 
on the server.


The lines we added to the server.xml file to get the secure port 
working are-




John Ellis




Hi, John-

Is it a browser that's displaying the error message and requesting that 
you create an exception to continue?  If so, have you looked at the 
additional information to determine what problems the browser has 
detected with the certificate?


-Terence Bandoian
 http://www.tmbsw.com/


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



Re: TomcatCon @ ApacheCon

2017-01-18 Thread Terence M. Bandoian

On 1/17/2017 4:04 PM, Mark Thomas wrote:

On 09/01/2017 11:57, Mark Thomas wrote:




I look forward to hearing your topic ideas.

Thanks for all the great ideas so far. I've tried to pull them all
together here:
https://cwiki.apache.org/confluence/display/TOMCAT/TomcatCon+NA+2017

I'm waiting to hear back from the ApacheCon folks as to how this would
work. I'll update this thread with info as I get it.

Mark



Nice.  Thank you.

-Terence Bandoian


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



Re: TomcatCon @ ApacheCon

2017-01-09 Thread Terence M. Bandoian

On 1/9/2017 8:00 AM, jean-frederic clere wrote:

On 01/09/2017 12:57 PM, Mark Thomas wrote:

All,

There is the opportunity (if we can pull it together as a community) to
run a dedicated Tomcat conference alongside ApacheCon NA 2017. The dates
are May 16 to 18.

The call for papers closes on Feb 11 so we have around a month to get
organised. We'll also need to convince the conference organisers that a)
there is a demand for this and b) we have a plan.

Getting the right content is going to be critical to success. I've been
thinking about this for a while and I think we can identify the right
content if as many folks as possible on this list answer the following
question:

"What topic(s) need to be covered in a Tomcat conference to make it as
easy as possible to get your employer to pay for you to attend?"

We have up to three days and potentially multiple tracks so even if you
think you have a niche requirement, please speak up. We typically have a
number of Tomcat committers speaking at ApacheCon so finding someone to
cover a particular topic shouldn't be too tricky. Equally, if you have a
topic you could present on that you think others would find useful,
speak up.

Do feel free to add your +1 if someone else mentions a topic your are
interested first. Having an idea of how popular the topics are would
also be helpful.

Also, we don't have to stick to the standard "Sit and listen to someone
present for 40 mins" format. Discussions, workshops, hackathons are all
possible.

Some topic ideas to get the ball rolling.

Hands-on workshop: Configuring TLS with Apache Tomcat
Reverse Proxying to Apache Tomcat
Load-balancing with Apache Tomcat
Clustering  with Apache Tomcat
Tomcat Clinic (like the users list but with everyone in the same room)

I look forward to hearing your topic ideas.

The classical tomcat-next (presenting 8.5 and 9 + migration + openssl)
easily fill a room and an afternoon of workshop.
Proxy and Load-balancing are also often asked...

What about tomcat in cloud?

Cheers

Jean-Frederic


Mark




Embedded Tomcat and microservices?  With and as an alternative to Spring 
Boot?


-Terence Bandoian
 http://www.tmbsw.com/


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



Re: Thread-safety of javax.servlet.Servlet#getServletConfig()

2016-12-05 Thread Terence M. Bandoian

On 12/5/2016 7:40 AM, Péter Gergely Horváth wrote:

Hi Chris,

Thanks your four input: this question is somewhere in-between... :)

We have *definitely* seen cases, where a piece of code like the one below
sometimes (a couple of times from tens of thousands of successfully
serviced requests) found the stored field to be null - with a
NullPointerException being thrown on the first access of the fooBarService
  field.

@WebServlet("/open")
public class FooBarServlet extends HttpServlet {

 private FooBarService fooBarService;
   @Override
 public void init() throws ServletException {
 try {
 ApplicationContext applicationContext =
 (ApplicationContext)
getServletContext().getAttribute("springContext");
 fooBarService =
 applicationContext.getBean("fooBarService",
FooBarService.class);

 } catch (Exception ex) {
 // wrap any exceptions to ServletException so as to comply with
Servlet contract
 throw new ServletException("Initialization failed with
exception", ex);



Does this exception ever occur?

-Terence Bandoian



 }
 }

 protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
 processRequest(request, response);
 }

 protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
 processRequest(request, response);
 }

 private void processRequest(HttpServletRequest request,
HttpServletResponse response) throws IOException, ServletException {

 List = fooBarService.getFooBars(); /// we have seen NPEs
thrown from here
/// ...
 }


For the first glance, it seemed to be obvious that it must have been a
threading issue, which could easily be solved by adding volatile to the
stored fooBarService field.

However, I was more than confused seeing
that javax.servlet.GenericServlet#config uses the same approach by simply
storing the ServletConfig into a field and reading it later on without any
locking etc.

I quickly scanned through the Servlet specs and Catalina codes, but cannot
really locate any explicit reference to thread-safety of
javax.servlet.GenericServlet#getServletConfig, that is where the question
originates.

I would by much obliged if you had any inputs, ideas regarding this, or on
the approach one could take to confirm it on his/her own.

Thanks,
Peter


On Mon, Nov 28, 2016 at 6:45 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Péter,

On 11/28/16 11:01 AM, Péter Gergely Horváth wrote:

Thank you very much for your feedback, but I think there is a
slight misunderstanding here: I know the order in which a servlet
is initialized and put into service, and this question is not
related to that. It's related to the _visibility_ of the field.

The question is about the thread safety of the field access: if
you carefully check the details of
javax.servlet.GenericServlet#config and compare the implementation
to the sample "NoVisibility" from the book Java Concurrency in
Practice, then it is seems to follow the same pattern, which is
"not thread-safe because the value field is accessed from both get
and set without synchronization. Among other hazards, it is
susceptible to stale values: if one thread calls set, other threads
calling get may or may not see that update." [1].

Personally, I would like to understand why this implementation is
not (if not) susceptible to the stale values phenomenon [2]; there
might be someone, who can point me to the right direction.

I think you are correct that there is a theoretical multi-threaded
race-condition, here. The container may initialize the servlet in one
thread and service e.g. the first request in another thread, and the
ServletContext reference might not be written to main memory and then
read-back by the request-processing thread.

Potential fixes for this would be either to define the ServletContext
member to be volatile or to use synchronized methods.'

Adding synchronization to the init() method would not be a problem at
all: there is very little monitor contention at that stage and the
container would only expect to call that method a single time. Adding
synchronization to the getServletContext method, though, might
represent a reduction in performance, since getServletContext gets
called many times during the lifetime of a Servlet, and from many thread
s.

Likewise, marking the ServletContext member as "volatile" would
necessarily require a slow main-memory read every time
getServletContext is called.

I suspect simple analysis above is the reason for no multithreaded
protection being placed on the ServletContext member in question.

Péter, is this an academic discussion, or have you in fact seen a case
where a servlet has been initialized and yet the first thread to
process a request receives a null 

Re: Header values when using HttpServletResponse.sendRedirect()

2016-09-08 Thread Terence M. Bandoian

On 9/8/2016 4:47 AM, Terence M. Bandoian wrote:

On 9/6/2016 2:36 PM, Joe Tseng wrote:

All,

I inherited a codebase that calls HttpServletResponse.sendRedirect() to
another page after a user is successfully logged in. I want to be 
able to

insert a header value before that redirection is executed. I tried to
simply add a HttpServletResponse.addHeader()/.setHeader() to the 
response
object before the redirect is called, but it seems a new response 
object is
used and sent to the browser. Is that assessment correct? Is there 
any way

for me to modify the redirect before it's sent or do I have to use
.forward()?

thx,

  - Joe




Rather than using sendRedirect, it should be possible to set any 
required headers and the status code using setHeader and setStatus.


-Terence Bandoian
 http://www.tmbsw.com/




Sorry about responding directly - I meant for my reply to go to the list.

-Terence


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



Re: [TOMCAT-JDBC] rs.absolute() throws "Invalid operation for forward only resultset: absolute"

2016-09-08 Thread Terence M. Bandoian

On 9/8/2016 3:20 AM, Mohamad Abbas wrote:

Hello,

I am working on a legacy web application running on a tomcat 8.0.37, and i
am getting an error "Invalid operation for forward only resultset:
absolute" when trying to use an InsensitiveScrollableResultSet (to paginate
results).

To make it simple and reproduce the problem i've created a test project who
contains the "Main" class below. The test project is executed on on a
windows 7, using jdk1.8.0_92. The only jars are present in the classpath of
the project are: tomcat-jdbc(8.0.37), tomcat-juli(8.8.37),
and ojdbc7-12.1.0.2.0.

Those are the steps to reproduce the problem:

- Create a Statement using the method .prepareStatement(String)=> OK
- Execute the query => OK (simple query: SELECT 1 FROM dual)
- Create a new Statement (with a SCROLL_INSENSITIVE type) for the same
query (SELECT 1 FROM dual) => KO (or OK?), tomcat-jdbc is returning the
cached Statement created in Step 1 (a FORWARD_ONLY Statement).
- Execute the query => OK
- Call absolute method => Exception: Invalid operation for forward only
resultset: absolute

I don't know if it is really a bug in tomcat-jdbc or if my problem is due
to a misconfiguration.

Here is the code:

package test;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;

import org.apache.tomcat.jdbc.pool.DataSource;
import org.apache.tomcat.jdbc.pool.PoolProperties;

public class Main {

 private static DataSource datasource;

 static {
 PoolProperties p = new PoolProperties();
 p.setUrl("jdbc:oracle:thin:@localhost:1531:test");
 p.setDriverClassName("oracle.jdbc.OracleDriver");
 p.setUsername("test");
 p.setPassword("test");
 p.setTestWhileIdle(true);
 p.setTestOnBorrow(false);
 p.setValidationQuery("SELECT 1 FROM dual");
 p.setValidationInterval(3);
 p.setMaxActive(1); // to simplify the test
 p.setInitialSize(1); // to simplify the test
 p.setMaxWait(1); // to simplify the test
 p.setMinEvictableIdleTimeMillis(3);
 p.setMinIdle(1); // to simplify the test
 p.setMaxIdle(1); // to simplify the test
 p.setJdbcInterceptors("StatementCache(max=10)"); // If i
replace max=10 by max = 0, the problem disappears
 datasource = new DataSource();
 datasource.setPoolProperties(p);
 }

 public static void main(String[] args) throws Exception {
 testWithForwardOnlyResultSet(datasource);
 testWithInsensitiveResultSet(datasource);
 }

 private static void testWithForwardOnlyResultSet(DataSource datasource)
throws Exception {
 Connection con = datasource.getConnection();
 PreparedStatement st = con.prepareStatement("select 1 from dual");
 ResultSet rs = st.executeQuery();
 while (rs.next()) {
 System.out.println("Result = " + rs.getString(1));
 }
 rs.close();
 st.close();
 con.close();
 }

 private static void testWithInsensitiveResultSet(DataSource datasource)
throws Exception {
 Connection con = datasource.getConnection();
 PreparedStatement st = con.prepareStatement("select 1 from dual",
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
 ResultSet rs = st.executeQuery();
 rs.absolute(1);
 while (rs.next()) {
 System.out.println("Result = " + rs.getString(1));
 }
 rs.close();
 st.close();
 con.close();
 }

}

Please tell me, if you need more informations.

Thanks for your help!



If a JDBC driver does not support TYPE_SCROLL_INSENSITIVE, it may fall 
back silently to TYPE_FORWARD_ONLY.


-Terence Bandoian
 http://www.tmbsw.com/


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



Re: How to write a correct HTTP request to Tomcat 8.5.4 instance?

2016-09-06 Thread Terence M. Bandoian

On 9/5/2016 8:09 AM, Klemens Muthmann wrote:

Am 05.09.2016 um 14:49 schrieb Tim Watts:

On Mon, 2016-09-05 at 14:11 +0200, Klemens Muthmann wrote:

Hi,

I currently need to implement an HTTP data transmission from an Arduino
with WiFi module to a PC running a Tomcat 8.5.4 instance. The Tomcat is
running under Ubuntu 16.04.

The problem is that, since there are no HTTP libraries on Arduino, I
need to write the correct HTTP request myself and I got stuck. It would
be great if someone on the list with a deeper understanding of the HTTP
protocol would be willing to support me.
The transmitted (possibly erroneous ) request looks like:


GET /push?VIN=testrun HTTP/1.1
User-Agent: Freematics
Connection: keep-alive
Host:


The server runs under a local access point IP (10.42.0.1) and receives
that request correctly but throws me an EOFException from the following
code fragment:

  nRead = channel.read(socketBufferHandler.getReadBuffer());
 if (nRead == -1) {
 throw new EOFException();
 }

So it seems to me that an end of file is reached before it is expected.
Can somebody provide me with hints on how to solve that issue and
formulate a correct HTTP request to my Tomcat instance?

The following is th log trace I receive from the server:

2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.a.coyote.http11.Http11InputBuffer  : Received [GET
/push?VIN=testrun HTTP/1.1
User-Agent: Freematics
Connection: keep-alive
Host:

]

Until a real expert comes along with a better answer let me just toss
this out:  Are the lines in the HTTP request that the Arduino submits
terminated with \r\n (and not just \n)?  Because it looks like the
entire request may have been read when reading the request line.  Then
when it goes to read the headers it gets an EOF.  Not 100% sure of this
but it's possible.



2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.a.c.authenticator.AuthenticatorBase: Security checking request GET
/push
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
org.apache.catalina.realm.RealmBase  :   No applicable constraints
defined
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.a.c.authenticator.AuthenticatorBase:  Not subject to any constraint
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
org.apache.tomcat.util.http.Parameters   : Set encoding to UTF-8
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
org.apache.tomcat.util.http.Parameters   : Decoding query null UTF-8
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
org.apache.tomcat.util.http.Parameters   : Start processing with input
[VIN=testrun]
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.s.b.w.f.OrderedRequestContextFilter: Bound request context to
thread: org.apache.catalina.connector.RequestFacade@75c83bc4
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.s.web.servlet.DispatcherServlet: DispatcherServlet with name
'dispatcherServlet' processing GET request for [/push]
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
s.w.s.m.m.a.RequestMappingHandlerMapping : Looking up handler method for
path /push
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
s.w.s.m.m.a.RequestMappingHandlerMapping : Returning handler method
[public void de.cyface.obd2.controller.Obd2Controller.push()]
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.s.b.f.s.DefaultListableBeanFactory : Returning cached instance of
singleton bean 'obd2Controller'
2016-09-05 13:32:50.238 DEBUG 13143 --- [nio-8080-exec-1]
o.s.web.servlet.DispatcherServlet: Last-Modified value for
[/push] is: -1
push
2016-09-05 13:32:50.239 DEBUG 13143 --- [nio-8080-exec-1]
o.s.web.servlet.DispatcherServlet: Null ModelAndView returned to
DispatcherServlet with name 'dispatcherServlet': assuming HandlerAdapter
completed request handling
2016-09-05 13:32:50.239 DEBUG 13143 --- [nio-8080-exec-1]
o.s.web.servlet.DispatcherServlet: Successfully completed request
2016-09-05 13:32:50.239 DEBUG 13143 --- [nio-8080-exec-1]
o.s.b.w.f.OrderedRequestContextFilter: Cleared thread-bound request
context: org.apache.catalina.connector.RequestFacade@75c83bc4
2016-09-05 13:32:50.239 DEBUG 13143 --- [nio-8080-exec-1]
o.apache.coyote.http11.Http11Processor   : Socket:
[org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper@2940dec1:org.apache.tomcat.util.net.NioChannel@34a92297:java.nio.channels.SocketChannel[connected
local=/10.42.0.1:8080 remote=/10.42.0.72:46701]], Status in:
[OPEN_READ], State out: [OPEN]
2016-09-05 13:32:55.280 DEBUG 13143 --- [nio-8080-exec-2]
o.apache.coyote.http11.Http11Processor   : Error parsing HTTP request header

java.io.EOFException: null
 at
org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.fillReadBuffer(NioEndpoint.java:1222)
~[tomcat-embed-core-8.5.4.jar:8.5.4]
 at

Re: Tomcat 8.x JvmOptions parameter length restrictions?

2016-08-29 Thread Terence M. Bandoian

On 8/29/2016 8:34 AM, Mekkelsen Madden, Steve wrote:

I've setup Tomcat 8.5.3 as a Windows Service (configured the service.bat file) and 
everything appears to be working fine.  I'm trying to find out if there are any 
restrictions to the overall length of the parameters which can be used in the service.bat 
for --JvmOptions " " ^ line.  This isn't specific to Tomcat 8.5.3 as I saw the 
same in 8.0.x versions as well.  So it may just be NotePad++ doing something funky.

What I'm seeing when using NotePad++, is at column 1024 the text looks fine.  
But for 16 characters after that, the text appears in light blue and the 
remaining line looks okay.  I can't tell if there is a setting in NotePad++ 
that is simply identifying the first 1024 characters or if the validate for the 
service.bat file is catching something I should be aware of.  Since this email 
is text only, it is hard to show it, so I've taken a screen shot and pasted it 
here: https://postimg.org/image/gv29etcdf/

I don't have any good way to verify if all the parameters did in fact load 
properly, so reaching out to others to see if they have the same issue and/or 
know how to resolve it.

Thanks,
Steve Mekkelsen Madden




The Tomcat Service Manager GUI may be used to set Tomcat system 
properties.  The Tomcat 32-bit/64-bit Windows Service Installer creates 
a shortcut to the GUI in the Windows start menu named "Configure 
Tomcat".  The executable for the service manager GUI is located in the 
Tomcat bin directory and named Tomcatw.exe.  It is also 
included in the 32-bit and 64-bit Windows zip downloads.


In addition, system properties may be set in catalina.properties which 
is located in the Tomcat conf directory.


Hope that helps.

-Terence Bandoian
 http://www.tmbsw.com/


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



Re: How to configure SPNEGO authentication with fallback to FORM auth?

2016-07-01 Thread Terence M. Bandoian

On 6/30/2016 7:52 AM, ken edward wrote:

I did get it to work. Simply merged existing spnego and form auth valves
together, I will try to post later..

On Fri, Jun 24, 2016 at 6:21 PM, Terence M. Bandoian <tere...@tmbsw.com>
wrote:


On 6/24/2016 10:45 AM, ken edward wrote:


On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas <ma...@apache.org> wrote:

On 24/06/2016 16:17, ken edward wrote:

On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas <ma...@apache.org> wrote:

On 24 June 2016 14:22:32 BST, ken edward <kedward...@gmail.com> wrote:

Hello,

I have tomcat 8 on linux, configured with kerberos/SPNEGO
authentication.
All works well, but if the client cannot use kerberos to authenticate,
it
will not fallback to FORM authentication.

I see some references that tomcat 8 does not do fallback negotiation
for
FORM auth. True?


Yes

Any workarounds?
Nothing simple. Both SPNEGO and FORM have their complications. You'll


need
to code some form of custom solution.

Have a look in the archives. This has come up before and I think there


is
some sample code that might get you most of the way there.



I had already searched the mail archives, and did not see any sample

code.


If anyone has any insight, please do post some code fragments.


I was thinking of this:
http://wiki.apache.org/tomcat/SSLWithFORMFallback

Not quite what you are looking for but it might help.


I guess I need to extend the SPNEGO valve code in tomcat 8 to handle

fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a
simple
and essential use case. Perplexing that it is not implemented.



If you get it working, you might consider submitting a patch.  Doing so
might save someone else from cursing under their breath.

-Terence Bandoian
http://www.tmbsw.com/



Sounds great!

-Terence


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



Re: Runtime Cloning of DataSource for Different DB?

2016-06-29 Thread Terence M. Bandoian

On 6/29/2016 1:44 AM, Mark Thomas wrote:

On 29/06/2016 05:12, Terence M. Bandoian wrote:

On 6/28/2016 3:56 AM, Mark Thomas wrote:

On 27/06/2016 22:35, Jerry Malcolm wrote:

Mark,

On 6/27/2016 1:07 PM, Mark Thomas wrote:

On 27/06/2016 17:44, Jerry Malcolm wrote:


I'm assuming that context.lookup(...) simply locates the "jdbc/myDB"
 tag in the context.xml file, pulls all of the parms out of
that tag, creates a DataSource object utilizing the parms, and returns
it.If that's the case, couldn't I create a variation/subclass
of the
Context object that modifies the url parm that it found in the
resource
tag and puts the desired db name into the url before constructing the
DataSource?

Sure.

You need to implement the appropriate factory and then specify your
factory class explicitly in the Resource element using the factory
attribute.

You probably want to start here for ideas on how to code up your
factory:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/factory/


or for a more specific example:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSourceFactory.java?view=annotate




Mark


Thanks so much.  This looks doable.  Just to make sure I have the big
picture correct

1) I will define a new custom resource that returns a custom context
object that I write.
2) On the  tag for my custom context resource I can put all of
the standard DataSource parms
3) I then call lookup() on this custom context passing the dbName in
4) This custom context will build an appropriate Reference object with
all the parms, instantiate a BasicDataSourceFactory, and call
getInstance(.) on the factory.

When I need an instance of the datasource:
   Context initContext = new InitialContext();
   Context envContext  =
(Context)initContext.lookup("java:/comp/env");
   MyDataSourceContext dsContext = (MyDataSourceContext)
envContext.lookup( "dsContext/myDSContext" );
   DataSource myDS = (DataSource) dsContext.getInstance(
"dbName" );

Am I getting close?

Yes, but I don't think you want to use custom NamingContexts. I think
there is a simpler way.

1. Write a custom DataSource factory that provides a getDataSource(...)
method that allows you to pass in whatever per instance config you need.
This DataSource factory will need to use bean style setters (like the
example I linked to) to pick up the other config from the 

2. Write a custom resource factory that returns an instance of your
DataSource factory.

3. Add a context Resource element for your DataSource factory,
remembering to use the factory element and specify the custom resource
factory from 2.

HTH,

Mark


If external configuration were not required, would there be a problem
instantiating a DataSource directly and setting any required properties
programmatically?  Would any functionality be lost?

The option of a global resource shared between multiple web apps is lost.

You'd need a mechanism (a statics would work) to store and retrieve the
DataSource.


Also, if there were base properties set in a  element, would
there be a problem using a copy of the properties from that data source,
modified as necessary, to instantiate a new DataSource?

No, but you'd need to be careful since multiple requests for the same
DataSource should return the same object. You'd need to be able to
differentiate between a request for a new DataSourece and a previously
created one.

Mark



Thanks!

-Terence


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



Re: Runtime Cloning of DataSource for Different DB?

2016-06-28 Thread Terence M. Bandoian

On 6/28/2016 3:56 AM, Mark Thomas wrote:

On 27/06/2016 22:35, Jerry Malcolm wrote:

Mark,

On 6/27/2016 1:07 PM, Mark Thomas wrote:

On 27/06/2016 17:44, Jerry Malcolm wrote:


I'm assuming that context.lookup(...) simply locates the "jdbc/myDB"
 tag in the context.xml file, pulls all of the parms out of
that tag, creates a DataSource object utilizing the parms, and returns
it.If that's the case, couldn't I create a variation/subclass of the
Context object that modifies the url parm that it found in the resource
tag and puts the desired db name into the url before constructing the
DataSource?

Sure.

You need to implement the appropriate factory and then specify your
factory class explicitly in the Resource element using the factory
attribute.

You probably want to start here for ideas on how to code up your factory:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/naming/factory/

or for a more specific example:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/dbcp/dbcp2/BasicDataSourceFactory.java?view=annotate



Mark


Thanks so much.  This looks doable.  Just to make sure I have the big
picture correct

1) I will define a new custom resource that returns a custom context
object that I write.
2) On the  tag for my custom context resource I can put all of
the standard DataSource parms
3) I then call lookup() on this custom context passing the dbName in
4) This custom context will build an appropriate Reference object with
all the parms, instantiate a BasicDataSourceFactory, and call
getInstance(.) on the factory.

When I need an instance of the datasource:
  Context initContext = new InitialContext();
  Context envContext  =
(Context)initContext.lookup("java:/comp/env");
  MyDataSourceContext dsContext = (MyDataSourceContext)
envContext.lookup( "dsContext/myDSContext" );
  DataSource myDS = (DataSource) dsContext.getInstance( "dbName" );

Am I getting close?

Yes, but I don't think you want to use custom NamingContexts. I think
there is a simpler way.

1. Write a custom DataSource factory that provides a getDataSource(...)
method that allows you to pass in whatever per instance config you need.
This DataSource factory will need to use bean style setters (like the
example I linked to) to pick up the other config from the 

2. Write a custom resource factory that returns an instance of your
DataSource factory.

3. Add a context Resource element for your DataSource factory,
remembering to use the factory element and specify the custom resource
factory from 2.

HTH,

Mark



If external configuration were not required, would there be a problem 
instantiating a DataSource directly and setting any required properties 
programmatically?  Would any functionality be lost?


Also, if there were base properties set in a  element, would 
there be a problem using a copy of the properties from that data source, 
modified as necessary, to instantiate a new DataSource?


-Terence Bandoian


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



Re: How to configure SPNEGO authentication with fallback to FORM auth?

2016-06-24 Thread Terence M. Bandoian

On 6/24/2016 10:45 AM, ken edward wrote:

On Fri, Jun 24, 2016 at 11:26 AM, Mark Thomas  wrote:


On 24/06/2016 16:17, ken edward wrote:

On Fri, Jun 24, 2016 at 10:46 AM, Mark Thomas  wrote:


On 24 June 2016 14:22:32 BST, ken edward  wrote:

Hello,

I have tomcat 8 on linux, configured with kerberos/SPNEGO
authentication.
All works well, but if the client cannot use kerberos to authenticate,
it
will not fallback to FORM authentication.

I see some references that tomcat 8 does not do fallback negotiation
for
FORM auth. True?

Yes


Any workarounds?

Nothing simple. Both SPNEGO and FORM have their complications. You'll

need

to code some form of custom solution.

Have a look in the archives. This has come up before and I think there

is

some sample code that might get you most of the way there.




I had already searched the mail archives, and did not see any sample

code.

If anyone has any insight, please do post some code fragments.

I was thinking of this:
http://wiki.apache.org/tomcat/SSLWithFORMFallback

Not quite what you are looking for but it might help.



I guess I need to extend the SPNEGO valve code in tomcat 8 to handle
fallback to FORM auth, similar to SSLWIthFORMFallback. aaarg. Such a simple
and essential use case. Perplexing that it is not implemented.




If you get it working, you might consider submitting a patch.  Doing so 
might save someone else from cursing under their breath.


-Terence Bandoian
http://www.tmbsw.com/


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



Apache Tomcat 9.0.0-M4 and http/2 on Mac OS X 10.11.4

2016-04-03 Thread Terence M. Bandoian

On 4/2/2016 10:29 PM, Tobias Soloschenko wrote:

Hi,

I am trying to get http/2 working on Mac OS X 10.11.4 - these are the steps I 
used:

1. Install Brew: http://brew.sh/

2. Download Apache Tomcat 9 https://tomcat.apache.org/download-90.cgi

3. Download Xcode command line tools by opening the terminal and execute 
“xcode-select  —install”

4. Download Xcode from the AppStore

5. Create a symlink for the xctoolchain:

sudo ln -s 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain 
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.11.xctoolchain

6. Install APR and OPENSSL with “brew install openssl” and “brew install apr”

7. Install tomcat native by extracting bin/tomcat-native.tar.gz and run “./configure 
--with-ssl=/usr/local/Cellar/openssl/1.0.2g --prefix=/Applications/apache-tomcat-9.0.0.M4 
--with-apr=/usr/local/Cellar/apr/1.5.2 && make && make install” in 
tomcat-native-1.2.5-src/native - see

https://tomcat.apache.org/tomcat-9.0-doc/apr.html

8. export JAVA_OPTS=-Djava.library.path=/usr/local/apr/lib

9. Create pem files in conf folder:

/usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -des3 -out 
localhost-rsa-key 1024

/usr/local/Cellar/openssl/1.0.2g/bin/openssl genrsa -out localhost-key 1024

/usr/local/Cellar/openssl/1.0.2g/bin/openssl rsa -in localhost-rsa-key -out 
localhost-key

/usr/local/Cellar/openssl/1.0.2g/bin/openssl req -new -key localhost-key -out 
localhost-csr

/usr/local/Cellar/openssl/1.0.2g/bin/openssl x509 -req -days 365 -in 
localhost-csr -signkey localhost-key -out localhost-crt

cat localhost-key localhost-crt > localhost-rsa-cert.pem

cat localhost-rsa-cert.pem > localhost-rsa-chain.pem

cat localhost-rsa-key > localhost-rsa-key.pem

10. Uncomment the http/2 connector in the server.xml



Is this procedure included in the Tomcat documentation?  Seems like it 
would be useful if it isn't.


Thanks.

-Terence Bandoian
 http://www.tmbsw.com/




I am currently facing those issues (out of the log):



02-Apr-2016 09:15:13.415 INFO [main] 
org.apache.catalina.startup.VersionLoggerListener.log Command line argument: 
-Djava.io.tmpdir=/Applications/apache-tomcat-9.0.0.M4/temp

02-Apr-2016 09:15:13.415 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based 
Apache Tomcat Native library 1.2.5 using APR version 1.4.8.

02-Apr-2016 09:15:13.415 INFO [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: 
IPv6 [true], sendfile [true], accept filters [false], random [true].

02-Apr-2016 09:15:13.418 SEVERE [main] 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Failed to 
initialize the SSLEngine.

  org.apache.tomcat.jni.Error: 70023: This function has not been implemented on 
this platform

at org.apache.tomcat.jni.SSL.initialize(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at 
org.apache.catalina.core.AprLifecycleListener.initializeSSL(AprLifecycleListener.java:284)

at 
org.apache.catalina.core.AprLifecycleListener.lifecycleEvent(AprLifecycleListener.java:136)

at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:94)

at 
org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:104)

at org.apache.catalina.startup.Catalina.load(Catalina.java:606)

at org.apache.catalina.startup.Catalina.load(Catalina.java:629)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:497)

at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)

at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)



02-Apr-2016 09:15:13.655 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing 
ProtocolHandler ["http-nio-8080"]

02-Apr-2016 09:15:13.683 INFO [main] 
org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared 
selector for servlet write/read

02-Apr-2016 09:15:13.686 INFO [main] 
org.apache.coyote.http11.AbstractHttp11Protocol.configureUpgradeProtocol The 
["https-apr-8443"] connector has been configured to support negotiation to [h2] 
via ALPN

02-Apr-2016 09:15:13.686 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing 
ProtocolHandler ["https-apr-8443"]

02-Apr-2016 09:15:13.706 WARNING [main] 
org.apache.tomcat.util.net.openssl.OpenSSLEngine. Failed getting cipher 
list

  java.lang.Exception: Not implemented

at org.apache.tomcat.jni.SSL.newSSL(Native Method)

at 

How to comply with http://www.sitemaps.org/protocol.html#location

2016-03-14 Thread Terence M. Bandoian

On 3/13/2016 10:23 AM, Lyallex wrote:

CentOS 5.2
jdk1.7.0_45
apache-tomcat-7.0.42
no httpd, tomcat only, one webapp ROOT.war

According to the documentation at

http://www.sitemaps.org/protocol.html#location

An xml sitemap should appear in the context root, if it dosn't it can
only contain a limited set of urls.

Currently, whenever I add a new product for sale I auto generate
sitemap.xml and write it to a remote context called sitemap giving me
the sitemap URL

www.mysite.com/sitemap/sitemap.xml which I detail in robots.txt

However this is apparently incorrect and sitemap.xml should live at
www.mysite.com/sitemap.xml. Unfortunately it is not possible to write
to the root of my web app on the fly so how do people deal with this ?

Thanks
Lyallex




One solution might be to write a servlet mapped to /sitemap.xml that 
reads sitemap.xml from an alternate location and sends the contents as a 
response to any requests for /sitemap.xml


-Terence Bandoian
 http://www.tmbsw.com/


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



Re: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-02 Thread Terence M. Bandoian

On 2/2/2016 2:49 AM, Yuval Schwartz wrote:



On Mon, Feb 1, 2016 at 7:36 PM, Terence M. Bandoian <tere...@tmbsw.com 
<mailto:tere...@tmbsw.com>> wrote:


On 2/1/2016 10:12 AM, Yuval Schwartz wrote:

Hello Terence,

Thanks for the input.
I shutdown the ScheduledExecutorService in the
contextDestroyed method of
the app's ServletContextListener class as well.
I also call shutDownNow() followed by an if statement with
!awaitTermination() as the condition.

Are you sure that the new warning that I'm getting is also
related to the
ScheduledExecutorService?
The warning again is:

WARNING [main] org.apache.tomcat.util.net
<http://org.apache.tomcat.util.net>.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has
not fully
shutdown. Some application threads may still be running

I didn't find much information about http-apr-8080 on google.
When I do a thread dump while tomcat is running I see
http-apr-8080-exec-1,
http-apr-8080-exec-2,...http-apr-8080-exec-10.
I'm not sure what these do? Are these threads the same as
http-apr-8080
that is referenced in the warning?

How else can I go about debugging this message?

Thank you



Hi, Yuval-

I'm not sure the new warning is related to the way the
ScheduledExecutorService is stopped.  You mentioned though that
the previous warning was related so I thought I'd share my
experience. Here's the code I used:

public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;

executor.shutdown();

do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );

executor = null;

Thread.yield();


Java docs say use of this method is rarely necessary...so I'm a little 
hesitant to use it.


}
}

Notice the loop.

For the new warning, my suggestion would be to find out who owns
the thread in question.  Can you do that with the profiler?


Thanks. I don't use a profiler. I'm using Jstack, and at the time the 
application is running, when I do a thread dump, I don't see this 
thread ("http-apr-8080").


I also did some testing on my development environment and printing the 
threads right before tomcat shuts down prints some threads, but again, 
none are named "http-apr-8080" (although some are named 
http-apr-8080-exec-...).



Hope that helps.

-Terence Bandoian




    On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian
<tere...@tmbsw.com <mailto:tere...@tmbsw.com>>
wrote:

On 2/1/2016 8:54 AM, Yuval Schwartz wrote:

Hello Mark,

I think that the issue below was related to the way I
was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is
destroyed...I will
update here if I don't receive any more warnings.

However, I now get a warning:

WARNING [main] org.apache.tomcat.util.net
<http://org.apache.tomcat.util.net>
.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool
[http-apr-8080] has not fully
shutdown. Some application threads may still be running

I am not sure if this is related or not?
When I do a heap dump with jstack I see
http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?

Thanks.


Hi, Yuval-

Where are you shutting down the ScheduledExecutorService? 
I ran into a

similar problem trying to stop a ScheduledExecutorService
in the
contextDestroyed method of a ServletContextListener. 
Adding a call to

Thread.yield() after the executor was terminated removed
the warning.  To
terminate the executor, I used the shutdown() method
followed by a loop
with a call to awaitTermination().

-Terence Bandoian




On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz
<yuval.schwa...

Re: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-02 Thread Terence M. Bandoian

On 2/1/2016 10:12 AM, Yuval Schwartz wrote:

Hello Terence,

Thanks for the input.
I shutdown the ScheduledExecutorService in the contextDestroyed method of
the app's ServletContextListener class as well.
I also call shutDownNow() followed by an if statement with
!awaitTermination() as the condition.

Are you sure that the new warning that I'm getting is also related to the
ScheduledExecutorService?
The warning again is:

WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

I didn't find much information about http-apr-8080 on google.
When I do a thread dump while tomcat is running I see http-apr-8080-exec-1,
http-apr-8080-exec-2,...http-apr-8080-exec-10.
I'm not sure what these do? Are these threads the same as http-apr-8080
that is referenced in the warning?

How else can I go about debugging this message?

Thank you



Hi, Yuval-

I'm not sure the new warning is related to the way the 
ScheduledExecutorService is stopped.  You mentioned though that the 
previous warning was related so I thought I'd share my experience. 
Here's the code I used:


public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;

executor.shutdown();

do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );

executor = null;

Thread.yield();
}
}

Notice the loop.

For the new warning, my suggestion would be to find out who owns the 
thread in question.  Can you do that with the profiler?


Hope that helps.

-Terence Bandoian




On Mon, Feb 1, 2016 at 5:59 PM, Terence M. Bandoian <tere...@tmbsw.com>
wrote:


On 2/1/2016 8:54 AM, Yuval Schwartz wrote:


Hello Mark,

I think that the issue below was related to the way I was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is destroyed...I will
update here if I don't receive any more warnings.

However, I now get a warning:

WARNING [main] org.apache.tomcat.util.net
.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

I am not sure if this is related or not?
When I do a heap dump with jstack I see http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?

Thanks.



Hi, Yuval-

Where are you shutting down the ScheduledExecutorService?  I ran into a
similar problem trying to stop a ScheduledExecutorService in the
contextDestroyed method of a ServletContextListener.  Adding a call to
Thread.yield() after the executor was terminated removed the warning.  To
terminate the executor, I used the shutdown() method followed by a loop
with a call to awaitTermination().

-Terence Bandoian





On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz <yuval.schwa...@gmail.com
wrote:



On Sunday, 31 January 2016, Mark Thomas <ma...@apache.org> wrote:

On 31/01/2016 08:06, Yuval Schwartz wrote:

Hellow Mark,

Thanks for the reply.
Follow up questions below.

On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas <ma...@apache.org> wrote:

On 29/01/2016 14:34, Yuval Schwartz wrote:

Hello,

tomcat version: 8.0.22
java: jdk1.8.0_05
server: Amazon Linux AMI

I get the following warning message in my catalina log when I


undeploy a

web application:

*WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]]



org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads


The

web application [ROOT##002] appears to have started a thread named
[pool-2-thread-1] but has failed to stop it. This is very likely to


create


a memory leak. Stack trace of thread*

As you can see, for some reason, I don't get a stack trace of the


thread.

Therefore, I have no idea how to debug this warning.

This particular warning was generated when tomcat detected an unused
version and undeployed it (I set undeployOldVersions="true").

Does anyone know how I can debug this warning. How can I know more


about

this thread?

That looks like a thread from Commons Pool (possibly via DBCP). The


only
way to be sure you have a leak or not is to use a profiler. See




http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf


Is VisualVM a good profiler to start with considering my system?


Sorry, don't know. Never used it. I use YourKit, mainly because they
kindly donate free licenses to OpenSource developers to use with their
OpenSource projects.


Thank you Mark,

I installed VisualVM a

Re: Tomcat Server - Arraylist java.util.ConcurrentModificationException issue

2016-02-02 Thread Terence M. Bandoian

On 2/2/2016 3:54 AM, Subhro Paul wrote:

From:   "Terence M. Bandoian" <tere...@tmbsw.com>
To: Tomcat Users List <users@tomcat.apache.org>
Date:   02/01/2016 07:58 PM
Subject:Tomcat Server - Arraylist
java.util.ConcurrentModificationException issue



On 2/1/2016 6:50 AM, Subhro Paul wrote:

Hi Team,

Our web application has a "header.jsp" which has 2  Arraylist on it.

Each

ArrayList has more than 50 items inside. The code is to identify the
mobile device and requested page and transfer the call to mobile page
accordingly.

This code works fine once we restart the server and can continue running

2

months without any issue. But day by day it starts showing 500 error

with

exception in log "ConcurrentModificationException". Below is the code
snippet of JSP code. My Question is why this issue is happening around 2
months? If we clear the temp file created by the server in work folder
then that will run for some time( 2- 3 days) and then again the same
exception starts occurring. I have identified one solution by moving the
JAVA code from JSP to JAVA file which worked good while perform testing
but client wants to know the root cause of the issue.

FYI, earlier we had Vector in place of Arraylist which gave trouble of
thread blocking due to synchronization. So, converting from Arraylist to
Vector will not be a good idea.


Exception:

java.util.ConcurrentModificationException
  at
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
  at java.util.ArrayList$Itr.next(ArrayList.java:831)
  at
org.apache.jsp.includes.header_jsp.isHomePage(header_jsp.java:97)


Code Snippet:

<%!
private Set uas = new HashSet();
ArrayList urlnames = new ArrayList();
ArrayList excludePathList = new ArrayList();


Hi, Subhro-

Fields declared in a declarations section (<%!  ... %>) are class



That should be "instance" variables.


  
variables.  If Tomcat uses a single JSP object to serve multiple

requests, which I believe it does, access to these fields should be made
thread safe.  A simple solution would be to move the declarations of
these fields to a scriptlet section (<% ... %>) which would result in
them being local to the JSP service method.  It isn't the most efficient
way to go about it but it should solve the concurrent access problem
you're seeing.

-Terence Bandoian
/http://www.tmbsw.com/
/


private boolean haveToRedirect(HttpServletRequest request,
  String stopMobiCookie) {
  boolean doRedirect = false;

  String userAgent = request.getHeader("User-Agent");
  if (! stopMobiCookie.equals("yes") && userAgent != null &&
userAgent.length()!=0 && (userAgent.indexOf("UsableNet")==-1))
  {

  Iterator iter = uas.iterator();
  while (iter.hasNext()) {
  if (userAgent.indexOf((String)iter.next())!=-1)

{

  doRedirect = true;
  break;


  }
  }
  }
  return doRedirect;
}

  private boolean isHomePage(HttpServletRequest request){
  Iterator itr = urlnames.iterator();
  String path = "";
  while (itr.hasNext()) {
   path = itr.next();
   if
(request.getRequestURI().toString().equalsIgnoreCase(path)){
   return true;
   }
  }
  return false;
  }

  private boolean isExcludePath(HttpServletRequest request){
  Iterator itr = excludePathList.iterator();
  String path = "";
  while (itr.hasNext()) {
   path = itr.next();
   if (request.getRequestURI().startsWith(path)

&&

!request.getRequestURI().startsWith("/info/contact.jsp")){
   return true;
   }
  }
  return false;
  }

%>


<%

uas.add("Blazer");
uas.add("Danger hiptop");
uas.add("DoCoMo/");
uas.add("Ericsson");
uas.add("Googlebot-Mobile");
uas.add("MSN Mobile Proxy");
uas.add("Handheld");
uas.add("HTC_HD2_T58585 Opera");
uas.add("iPhone");
uas.add("iPod");
uas.add("Klondike");
uas.add("LG-");
uas.add("LGE-");
... Arround 40 items


excludePathList.add("/business/my_account");
excludePathList.add("/business/save_energy");
excludePathList.add("/business/services");
excludePathList.add("/business/small_large_business");
excludePathList.add("/info/environment")

Tomcat Server - Arraylist java.util.ConcurrentModificationException issue

2016-02-01 Thread Terence M. Bandoian

On 2/1/2016 6:50 AM, Subhro Paul wrote:

Hi Team,

Our web application has a "header.jsp" which has 2  Arraylist on it. Each
ArrayList has more than 50 items inside. The code is to identify the
mobile device and requested page and transfer the call to mobile page
accordingly.

This code works fine once we restart the server and can continue running 2
months without any issue. But day by day it starts showing 500 error with
exception in log "ConcurrentModificationException". Below is the code
snippet of JSP code. My Question is why this issue is happening around 2
months? If we clear the temp file created by the server in work folder
then that will run for some time( 2- 3 days) and then again the same
exception starts occurring. I have identified one solution by moving the
JAVA code from JSP to JAVA file which worked good while perform testing
but client wants to know the root cause of the issue.

FYI, earlier we had Vector in place of Arraylist which gave trouble of
thread blocking due to synchronization. So, converting from Arraylist to
Vector will not be a good idea.


Exception:

java.util.ConcurrentModificationException
 at
java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
 at java.util.ArrayList$Itr.next(ArrayList.java:831)
 at
org.apache.jsp.includes.header_jsp.isHomePage(header_jsp.java:97)


Code Snippet:

<%!
private Set uas = new HashSet();
ArrayList urlnames = new ArrayList();
ArrayList excludePathList = new ArrayList();



Hi, Subhro-

Fields declared in a declarations section (<%!  ... %>) are class 
variables.  If Tomcat uses a single JSP object to serve multiple 
requests, which I believe it does, access to these fields should be made 
thread safe.  A simple solution would be to move the declarations of 
these fields to a scriptlet section (<% ... %>) which would result in 
them being local to the JSP service method.  It isn't the most efficient 
way to go about it but it should solve the concurrent access problem 
you're seeing.


-Terence Bandoian
/http://www.tmbsw.com/
/



private boolean haveToRedirect(HttpServletRequest request,
 String stopMobiCookie) {
 boolean doRedirect = false;
  
 String userAgent = request.getHeader("User-Agent");

 if (! stopMobiCookie.equals("yes") && userAgent != null &&
userAgent.length()!=0 && (userAgent.indexOf("UsableNet")==-1))
 {

 Iterator iter = uas.iterator();
 while (iter.hasNext()) {
 if (userAgent.indexOf((String)iter.next())!=-1) {
 doRedirect = true;
 break;


 }
 }
 }
 return doRedirect;
}

 private boolean isHomePage(HttpServletRequest request){
 Iterator itr = urlnames.iterator();
 String path = "";
 while (itr.hasNext()) {
  path = itr.next();
  if
(request.getRequestURI().toString().equalsIgnoreCase(path)){
  return true;
  }
 }
 return false;
 }
  
 private boolean isExcludePath(HttpServletRequest request){

 Iterator itr = excludePathList.iterator();
 String path = "";
 while (itr.hasNext()) {
  path = itr.next();
  if (request.getRequestURI().startsWith(path) &&
!request.getRequestURI().startsWith("/info/contact.jsp")){
  return true;
  }
 }
 return false;
 }

%>


<%

uas.add("Blazer");
uas.add("Danger hiptop");
uas.add("DoCoMo/");
uas.add("Ericsson");
uas.add("Googlebot-Mobile");
uas.add("MSN Mobile Proxy");
uas.add("Handheld");
uas.add("HTC_HD2_T58585 Opera");
uas.add("iPhone");
uas.add("iPod");
uas.add("Klondike");
uas.add("LG-");
uas.add("LGE-");
... Arround 40 items


excludePathList.add("/business/my_account");
excludePathList.add("/business/save_energy");
excludePathList.add("/business/services");
excludePathList.add("/business/small_large_business");
excludePathList.add("/info/environment");
excludePathList.add("/info/about");
excludePathList.add("/info/index.jsp");
excludePathList.add("/info/ambassador.jsp");
 more than 50 items


stopMobiCookie = some cookie code

boolean doRedirect = haveToRedirect((HttpServletRequest)request,
stopMobiCookie);


if(doRedirect){
 boolean isHomePage =
isHomePage((HttpServletRequest)request);
 boolean isExcludePath =
isExcludePath((HttpServletRequest)request);
  
 session.setAttribute("mobile_agent", "yes");


 if(!isHomePage && !isExcludePath){
 String mobileServer = "mobile.server.com";

Re: WebAppClassLoaderBase.clearReferencesThreads warning

2016-02-01 Thread Terence M. Bandoian

On 2/1/2016 8:54 AM, Yuval Schwartz wrote:

Hello Mark,

I think that the issue below was related to the way I was shutting down an
instance of ScheduledExecutorService.
I changed the way it is shutdown when the context is destroyed...I will
update here if I don't receive any more warnings.

However, I now get a warning:

WARNING [main] org.apache.tomcat.util.net.AbstractEndpoint.shutdownExecutor
The executor associated with thread pool [http-apr-8080] has not fully
shutdown. Some application threads may still be running

I am not sure if this is related or not?
When I do a heap dump with jstack I see http-apr-8080-exec-[1-10] but I
don't see any thread named http-apr-8080.
Any ideas on how to trouble shoot this?

Thanks.



Hi, Yuval-

Where are you shutting down the ScheduledExecutorService?  I ran into a 
similar problem trying to stop a ScheduledExecutorService in the 
contextDestroyed method of a ServletContextListener.  Adding a call to 
Thread.yield() after the executor was terminated removed the warning.  
To terminate the executor, I used the shutdown() method followed by a 
loop with a call to awaitTermination().


-Terence Bandoian




On Sun, Jan 31, 2016 at 8:18 PM, Yuval Schwartz 
wrote:



On Sunday, 31 January 2016, Mark Thomas  wrote:


On 31/01/2016 08:06, Yuval Schwartz wrote:

Hellow Mark,

Thanks for the reply.
Follow up questions below.

On Fri, Jan 29, 2016 at 6:22 PM, Mark Thomas  wrote:


On 29/01/2016 14:34, Yuval Schwartz wrote:

Hello,

tomcat version: 8.0.22
java: jdk1.8.0_05
server: Amazon Linux AMI

I get the following warning message in my catalina log when I

undeploy a

web application:

*WARNING [ContainerBackgroundProcessor[StandardEngine[Catalina]]]


org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads

The

web application [ROOT##002] appears to have started a thread named
[pool-2-thread-1] but has failed to stop it. This is very likely to

create

a memory leak. Stack trace of thread*

As you can see, for some reason, I don't get a stack trace of the

thread.

Therefore, I have no idea how to debug this warning.

This particular warning was generated when tomcat detected an unused
version and undeployed it (I set undeployOldVersions="true").

Does anyone know how I can debug this warning. How can I know more

about

this thread?

That looks like a thread from Commons Pool (possibly via DBCP). The

only

way to be sure you have a leak or not is to use a profiler. See



http://home.apache.org/~markt/presentations/2010-11-04-Memory-Leaks-60mins.pdf


Is VisualVM a good profiler to start with considering my system?

Sorry, don't know. Never used it. I use YourKit, mainly because they
kindly donate free licenses to OpenSource developers to use with their
OpenSource projects.


Thank you Mark,

I installed VisualVM as a profiler.
I can now see all of the threads that tomcat is "using" (?not sure if
that's the correct term) (there's 35 live threads and 33 daemon threads).
Do you have any recommendations for how I might trouble shoot the original
warning that I got? Would I do a "heap dump"?
I have restarted tomcat since the time of the original warning message, so
I can't expect to find the same thread, correct?
Any tips?

FYI: I never saw my cpu climbing or anything, I am troubleshooting this
warning solely on seeing the "Warning" message. Is this overkill? Should I
wait until something more severe occurs? (I have not yet gone live with my
webapp but planned on doing so soon).

Thanks.



Mark


I would just like to confirm that this warning is not something serious.
I am currently having a little trouble running VisualVM (jstatd) from a
remote machine but can struggle with it a little more to try to get it
working.


Thanks.




I used the manager app and clicked "find leaks" but it said that there

were

none.
(Can someone also explain why I have to be cautious when using this

feature

on production environments).

It triggers a full GC which may (hopefully briefly) pause the entire

JVM.

Mark


-
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



Re: switching between Java8 and Java 7 under tomcat7 leads to error

2016-01-25 Thread Terence M. Bandoian

On 1/25/2016 12:34 PM, George Sexton wrote:



On 1/25/2016 3:52 AM, Christoph P.U. Kukulies wrote:

Thanks. Will give that a try.

How can I tell, which java engine Tomcat is actually using?

At a CMD prompt I'm getting:


C:\> java -version
java version "1.8.0_71"
Java(TM) SE Runtime Environment (build 1.8.0_71-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.71-b15, mixed mode)


If you have a utility that shows what open files the Tomcat process 
has, that would work. Alternatively, get the Manager application 
running and see what information it provides under the Server Status 
screen.




Also, the Tomcat Windows Service Installer includes a configuration 
utility (I'm not sure about the zip downloads).  In the Java tab of the 
utility, the JVM may be selected.


-Terence Bandoian
/http://www.tmbsw.com/
/





--
Christoph


At Am 22.01.2016 um 18:28 schrieb George Sexton:



On 1/22/2016 6:06 AM, Christoph P.U. Kukulies wrote:

Windows 7:

Today I installed Java 8 on my windows 7 machine and did an upgrade 
of the CMS at the same time (from OpenCMS 9.5.2 to 9.5.3).
After the Java update and the CMS update suddenly my tomcat 6.0.39 
didn't start any longer. The service gave an error at start time:


Der Dienst "Apache Tomcat 6.0 Tomcat6" wurde mit folgendem 
dienstspezifischem Fehler beendet: Unzulässige Funktion..




I've seen this on Windows when upgrading the JRE. The solution that 
worked for me (multiple times) was to uninstall Java, and then 
re-install it. Make sure you grab the correct version (x86, x64) to 
go with your Tomcat install.




My thoughts came to tomcat6 possibly not being compatible with 
Java8 and so I decided to install tomcat 7.0 which started fine.


When starting my CMS system again I now found that it did some 
unpleasant things for which I wanted to rule out tomcat7 being the 
culprit
and switch the jvm.dll in the tomcat7 configurator to the jre1.7 
jvm.dll.


Then suddenly I got the same error as under tomcat6.0 when I tried 
to start tomcat7 again.


Could it be that the Java8 installer screws the existing Java 7 ? 
Or does it change some global parameters that tomcat reads at start 
time.



Thanks.

--
Christoph





-
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: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

2016-01-15 Thread Terence M. Bandoian

On 1/13/2016 12:18 PM, McDermott, Becky wrote:

My problem has been solved.  In the tomcat7w.exe, I had to add the following to 
the Java Options:

-Djava.library.path=\PROGRA~1\IBM\JazzTeamServer_601\server\tomcat\lib

I also had to remove:
-Xgc:preferredHeapBase=1

With the removal of -Xgc and the addition of the -Djava.library.path, the 
service successfully started.


Nice work!

-Terence



-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Tuesday, January 12, 2016 6:46 PM
To: Tomcat Users List
Subject: RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

On 1/12/2016 10:04 AM, McDermott, Becky wrote:

I used the Java options provided by IBM.  Since Tomcat will successfully start 
using the startup batch files, I assume that these settings are fine.  I've 
tried playing with the settings and cannot get it to work either.  I seems like 
it's some sort of weird Windows thing.

I have successfully configured these services before with prior version of 
IBM's CLM.  The difference in those previous versions was that Tomcat came 
bundled with t heir product.  For this latest IBM version, Tomcat was not 
bundled and they provided instructions for downloading it from Apache and 
instructions for where to install it.

I have escalated the issue with IBM's support and since they are providing the JVM, it is 
probably their issue but wanted to put it out to the larger community to see if anyone 
has ever had this issue before.  A user on the user forums said that the memory error in 
the Tomcat log file is a red herring and that it is giving that memory allocation error 
because the JVM didn't actually start.  So, the issue seems more connected to the error 
in the Windows Event viewer ("cannot open file").


Hi, Becky-

Have you tried the Tomcat Windows Service Installer available on the download 
page (http://tomcat.apache.org/download-70.cgi)?  In my experience, it makes it 
much easier to get Tomcat up and running as a Windows service.  In addition, a 
configuration app is included which further simplifies the process.

With your current setup, I'd start by checking the Log On settings of the 
service and the permissions of the Tomcat files and folders.

-Terence Bandoian



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, January 12, 2016 8:59 AM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows
Service

Becky,

On 1/12/16 10:42 AM, McDermott, Becky wrote:

I am integrating Tomcat with the IBM CLM 6.0.1 collaboration tools.  Per IBM's 
installation instructions, I downloaded and extracted Tomcat 7.0.59 to my 
server.

I am successfully able to start the Tomcat server from the command line using 
the batch files provided by the IBM application (C:\Program 
Files\IBM\JazzTeamServer_601\server\server.startup.bat).  Tomcat starts as well 
as all of the IBM CLM applications.

The problem I'm having is when I try to configure tomcat to run as a Windows 
service.  I have followed the instructions provided by IBM:


1.   Set the environment variable CATALINA_HOME to C:\Program 
Files\IBM\JazzTeamServer_601\server\tomcat

2.   Deleted existing tomcat7 services using:  sc delete tomcat7

3.   Re-booted the machine

Note that, depending upon how you set the CATALINA_HOME environment variable, 
rebooting will lose this value. I'm not sure the reboot was necessary.


4.   Installed the new tomcat service from the Tomcat bin directory:  
service.bat install tomcat7

5.   Configured the service using:  tomcat7w.exe

1.   Clicked "Java" tab

2.   Cleared "Use default" checkbox

3.   Added the following path to the Java Virtual machine:  C:\Program 
Files\IBM\JazzTeamServer_601\server\jre\bin\j9vm\jvm.dll

4.   Added the following lines to the end of the java Options text field:
-DJAZZ_HOME=le:///C:/PROGRA~1/IBM/JazzTeamServer_601/server/conf
-Djava.awt.headless=ue
-Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin>> >tr ue 
-Dcom.ibm.team.repository.tempDir=C:\Program
Files\IBM\JazzTeamServer_601\server\tomcat\temp
-Djazz.connector.sslEnabledProtocols=Sv1.2
-Djazz.connector.algorithm=mX509
-Dlog4j.configuration=le:///C:/PROGRA~1/IBM/JazzTeamServer_601/ser
ve
r/conf/startup_log4j.properties
-Xgcpolicy:gencon
-Xcompressedrefs
-Xgc:preferredHeapBase=1
-XX:MaxDirectMemorySize=

That's a BIG buffer. Do you need 1G NIO buffers? A web-based video-editing 
application?


-Xmx4G
-Xms4G
-Xmn1g

What is -Xmn? It's probably not a problem, but I thought I'd point-out 
something that looks weird.


-DORACLE_JDBC_DRIVER_FILE=\Program
Files\IBM\JazzTeamServer_601\server\Oracle\ojdb6.jar

5.   Cleared the following fields:

* Initial memory pool

* Maximum memory pool

* Thread stack size

6.   In the Startup and Shutdown tabs, confirmed that &qu

RE: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

2016-01-12 Thread Terence M. Bandoian

On 1/12/2016 10:04 AM, McDermott, Becky wrote:

I used the Java options provided by IBM.  Since Tomcat will successfully start 
using the startup batch files, I assume that these settings are fine.  I've 
tried playing with the settings and cannot get it to work either.  I seems like 
it's some sort of weird Windows thing.

I have successfully configured these services before with prior version of 
IBM's CLM.  The difference in those previous versions was that Tomcat came 
bundled with t heir product.  For this latest IBM version, Tomcat was not 
bundled and they provided instructions for downloading it from Apache and 
instructions for where to install it.

I have escalated the issue with IBM's support and since they are providing the JVM, it is 
probably their issue but wanted to put it out to the larger community to see if anyone 
has ever had this issue before.  A user on the user forums said that the memory error in 
the Tomcat log file is a red herring and that it is giving that memory allocation error 
because the JVM didn't actually start.  So, the issue seems more connected to the error 
in the Windows Event viewer ("cannot open file").



Hi, Becky-

Have you tried the Tomcat Windows Service Installer available on the 
download page (http://tomcat.apache.org/download-70.cgi)?  In my 
experience, it makes it much easier to get Tomcat up and running as a 
Windows service.  In addition, a configuration app is included which 
further simplifies the process.


With your current setup, I'd start by checking the Log On settings of 
the service and the permissions of the Tomcat files and folders.


-Terence Bandoian




-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, January 12, 2016 8:59 AM
To: Tomcat Users List
Subject: [EXTERNAL] Re: Problem starting Tomcat 7.0.59 as a Windows Service

Becky,

On 1/12/16 10:42 AM, McDermott, Becky wrote:

>I am integrating Tomcat with the IBM CLM 6.0.1 collaboration tools.  Per IBM's 
installation instructions, I downloaded and extracted Tomcat 7.0.59 to my server.
>
>I am successfully able to start the Tomcat server from the command line using 
the batch files provided by the IBM application (C:\Program 
Files\IBM\JazzTeamServer_601\server\server.startup.bat).  Tomcat starts as well as 
all of the IBM CLM applications.
>
>The problem I'm having is when I try to configure tomcat to run as a Windows 
service.  I have followed the instructions provided by IBM:
>
>
>1.   Set the environment variable CATALINA_HOME to C:\Program 
Files\IBM\JazzTeamServer_601\server\tomcat
>
>2.   Deleted existing tomcat7 services using:  sc delete tomcat7
>
>3.   Re-booted the machine

Note that, depending upon how you set the CATALINA_HOME environment variable, 
rebooting will lose this value. I'm not sure the reboot was necessary.


>4.   Installed the new tomcat service from the Tomcat bin directory:  
service.bat install tomcat7
>
>5.   Configured the service using:  tomcat7w.exe
>
>1.   Clicked "Java" tab
>
>2.   Cleared "Use default" checkbox
>
>3.   Added the following path to the Java Virtual machine:  C:\Program 
Files\IBM\JazzTeamServer_601\server\jre\bin\j9vm\jvm.dll
>
>4.   Added the following lines to the end of the java Options text field:
>-DJAZZ_HOME=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/server/conf
>-Djava.awt.headless=true
>-Dorg.eclipse.emf.ecore.plugin.EcorePlugin.doNotLoadResourcesPlugin=tr
>ue -Dcom.ibm.team.repository.tempDir=C:\Program
>Files\IBM\JazzTeamServer_601\server\tomcat\temp
>-Djazz.connector.sslEnabledProtocols=TLSv1.2
>-Djazz.connector.algorithm=IbmX509
>-Dlog4j.configuration=file:///C:/PROGRA~1/IBM/JazzTeamServer_601/serve
>r/conf/startup_log4j.properties
>-Xgcpolicy:gencon
>-Xcompressedrefs
>-Xgc:preferredHeapBase=0x1
>-XX:MaxDirectMemorySize=1G

That's a BIG buffer. Do you need 1G NIO buffers? A web-based video-editing 
application?


>-Xmx4G
>-Xms4G
>-Xmn1g

What is -Xmn? It's probably not a problem, but I thought I'd point-out 
something that looks weird.


>-DORACLE_JDBC_DRIVER_FILE=C:\Program
>Files\IBM\JazzTeamServer_601\server\Oracle\ojdb6.jar
>
>5.   Cleared the following fields:
>
>* Initial memory pool
>
>* Maximum memory pool
>
>* Thread stack size
>
>6.   In the Startup and Shutdown tabs, confirmed that "jvm" was selected for the 
"Mode" setting
>
>When I try to start the service from Windows Services, I receive the following 
error:
>
>Services
>Windows could not start the Apache Tomcat 7.0 tomcat7 on Local Computer.  For 
more information, review the System Event Log.  If this is a non-Microsoft 
service, contact the service vendor and refer to service-specific error code 4.
>
>When I look at the Windows Event Viewer, there is an error that corresponds to 
the time I tried to start the service:
>
>The Apache Tomcat 7.0 tomcat7 service terminated with the following 
service-specific error:
>The system 

Detecting Expired Session via JavaScript?

2015-12-02 Thread Terence M. Bandoian

On 12/1/2015 11:30 AM, Jerry Malcolm wrote:
I'm looking for a way to detect that the current session has expired 
(or logged out via another tab on the browser).  I know I could just 
issue dummy requests to the server and see if a login page comes 
back.  But issuing requests automatically resets the session timer. I 
need a benign way to query that doesn't keep the session alive forever.


I'm sure this problem has been solved before.  But basically, I want 
to know that the session is no longer valid and force the user back to 
the login page.  I know one possibility is to set the Tomcat timer to 
30 min expiration, and then keep a '29 minute' timer running in the 
browser.  But my clients can change the tomcat session timer length.  
And also this doesn't account for a logoff using the same session on a 
different browser tab.  I'd really like a pro-active query method if 
anything like that exists.


Suggestion?

Thanks.

Jerry



One problem with checking the session status from the browser is time.  
A response may be received from the server that indicates the session 
has not expired BUT, the session may then expire before the next message 
is sent.


-Terence Bandoian


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



RE: The resource path [...] is not valid

2015-10-02 Thread Terence M. Bandoian

On 10/2/2015 10:28 AM, Chen Yang wrote:

I wonder if it's because of this?

org.apache.fop.servlet.FopServlet$1.getResource(FopServlet.java:116)

this.uriResolver = new ServletContextURIResolver(getServletContext());
 this.transFactory = TransformerFactory.newInstance();
 this.transFactory.setURIResolver(this.uriResolver);
 //Configure FopFactory as desired
 ResourceResolver resolver = new ResourceResolver() {
 public OutputStream getOutputStream(URI uri) throws IOException {
 URL url = getServletContext().getResource(uri.toASCIIString());
 return url.openConnection().getOutputStream();
 }

 public Resource getResource(URI uri) throws IOException {
 return new 
Resource(getServletContext().getResourceAsStream(uri.toASCIIString()));
//line 116
 }
 };
 FopFactoryBuilder builder = new FopFactoryBuilder(new 
File(".").toURI(), resolver);

root cause
java.lang.IllegalArgumentException: The resource path 
[file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%208.0/] is not 
valid

org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:250)

org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:212)

org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:206)
org.apache.fop.servlet.FopServlet$1.getResource(FopServlet.java:116)

org.apache.fop.apps.io.InternalResourceResolver.getResource(InternalResourceResolver.java:92)

org.apache.fop.apps.io.InternalResourceResolver.getResource(InternalResourceResolver.java:78)
org.apache.fop.apps.FOUserAgent.resolveURI(FOUserAgent.java:411)
org.apache.fop.apps.FOUserAgent$1.resolveURI(FOUserAgent.java:160)

org.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.newSource(AbstractImageSessionContext.java:92)

org.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.needSource(AbstractImageSessionContext.java:191)

org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:123)

org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81)
org.apache.fop.fo.FObj.processNode(FObj.java:129)

org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:291)
org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179)

com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.closeStartTag(Unknown
 Source)

com.sun.org.apache.xml.internal.serializer.ToSAXHandler.flushPending(Unknown 
Source)

com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(Unknown 
Source)

com.sun.org.apache.xml.internal.serializer.ToXMLSAXHandler.endElement(Unknown 
Source)
GregorSamsa.insert_cover_page_template()
GregorSamsa.template$dot$0()
GregorSamsa.applyTemplates()
GregorSamsa.transform()

com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(Unknown
 Source)

com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown 
Source)

com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown 
Source)
org.apache.fop.servlet.FopServlet.render(FopServlet.java:397)
org.apache.fop.servlet.FopServlet.renderXML(FopServlet.java:342)
org.apache.fop.servlet.FopServlet.doGet(FopServlet.java:150)
javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Friday, October 02, 2015 11:05 AM
To: Tomcat Users List
Subject: Re: The resource path [...] is not valid

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chen,

On 10/2/15 10:42 AM, Chen Yang wrote:

>I'm transforming xml into pdf files, but getting this strange error in
>my log. (tomcat 8.0.26)
>
>The resource path
>[file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%208.0/

]

>is not valid
>
>Here is my code
>
>//Setup sources StreamSource xmlSrc = new StreamSource(new URL(rootUrl
>+ "/output/xml/" + xml).openStream()); StreamSource xsltSrc = new
>StreamSource(new URL(rootUrl + "/output/xslt/" + xslt).openStream());

What's the value of "rootUrl"?


>//Setup the XSL transformation Transformer transformer =
>this.transFactory.newTransformer(xsltSrc);  //error out
>transformer.setURIResolver(this.uriResolver);
>
>XML & XSLT file are not stored locally, so I don't understand why it's
>looking at the tomcat folder?

What's the stack trace?

- -chris



Are you able to execute the 

Re: Need configuration example for Tomcat 7.0.55 TLS configuration

2015-04-06 Thread Terence M. Bandoian

On 4/6/2015 2:11 AM, Ognjen Blagojevic wrote:

Tom,

On 5.4.2015 3:06, Tom Williamson wrote:

I would like to know if anyone has a working example of getting TLS 1.2
working on Tomcat 7.0.55, so that it can be accessed by the latest
version of Chrome and Firefox.


Which version of Java do you use? Make sure it is Java 7 or 8, and if 
you already didn't upgrade, then upgrade to the latest released version.


Could you clarify do you need TLSv1.2 only, or you need TLSv1.2 among 
other TLS versions (v1 and v1.1)?




Connector port=8484 protocol=HTTP/1.1 SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   keystoreFile=/path/mykeystore
   keystorePass=password
   clientAuth=false
   sslProtocol=TLS
   sslEnabledProtocols=TLS /


By specifing protocol=HTTP/1.1 you are using connector 
auto-detection. Depending on the existance of Tomcat native DLL, 
Tomcat will automatically select between APR connector and JSSE 
connector. Those two connectors have completely different set of 
options. The options you are using (keystoreFile, keystorePass), are 
clearly indicating you wish to use JSSE connectors. Therefore, to rule 
out present and future auto-detection problems, I would recommend that 
you explicitly specify connector you wish to use. E.g. for JSSE BIO 
connector that would be:


  protocol=org.apache.coyote.http11.Http11Protocol


Next, sslEnabledProtocols should specify exact TLS versions, so if you 
need only TLSv1.2 use:


  sslEnabledProtocols=TLSv1.2

and if you need e.g. all three versions, then omit attribute 
sslEnabledProtocols, or use:


  sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2



So far based on the Tomcat 7.0 docs, I have tried the following
configuration changes:

sslEnabledProtocols=TLS
sslEnabledProtocols=TLSv1
sslEnabledProtocols=TLSv1.1
sslEnabledProtocols=TLSv1.2
sslEnabledProtocols=TLSv1.1,TLSv1.2


Except for the first one, all other examples should be working.



With most of these, I don't get any error in the console (I have logging
set to ALL), but I also have not been able to get either Chrome or
Firefox to connect.

I have also tried various combinations of sslProtocols= and cipher=,
also with no luck.

Can anyone post a sample connector configuration that works?


Try this:

Connector port=443
   protocol=org.apache.coyote.http11.Http11Protocol
   SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   clientAuth=false
   keystoreFile=/path/mykeystore
   keystorePass=password
   sslProtocol=TLS
   sslEnabledProtocols=TLSv1.2 /

BTW, the attribute name is ciphers, not cipher.

-Ognjen




Nicely done!

-Terence Bandoian


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



Re: SPNEGO test configuration with Manager webapp

2015-03-25 Thread Terence M. Bandoian

On 3/25/2015 2:19 PM, André Warnier wrote:

David Marsh wrote:

Javas version of kinit seems to report issue ?

C:\Program Files\Apache Software Foundation\Tomcat 
8.0\confC:\Program Files\Ja

va\jdk1.8.0_40\bin\kinit -t -k c:\keytab\tomcat.keytab
Exception: krb_error 0 Do not have keys of types listed in 
default_tkt_enctypes

available; only have keys of following type:  No error
KrbException: Do not have keys of types listed in 
default_tkt_enctypes available

; only have keys of following type:
at 
sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
at 
sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
at 
sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
at 
sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)

at sun.security.krb5.internal.tools.Kinit.init(Kinit.java:219)
at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)


That seems to indicate that between the Java Kerberos module in 
Tomcat, and the KDC's Kerberos software, there is a mismatch in the 
types of keys used (type of encryption), so they do not understand 
eachother.

This may be relevant : https://community.igniterealtime.org/thread/49913

It is also a bit strange that it says :
only have keys of following type:
(with nothing behind the :.. )

From what I keep browsing on the WWW, it also seems that the types of 
key encryptions that might match between Java Kerberos and Windows 
Kerberos, depend on the versions of both Java and Windows Server..


Man, this thing is really a nightmare, isn't it ?






From: dmars...@outlook.com
To: users@tomcat.apache.org
Subject: RE: SPNEGO test configuration with Manager webapp
Date: Wed, 25 Mar 2015 16:50:47 +

Its possible I guess, although I would not expect that.

The test is :-

Client Test Windows 8.1 VM with Firefox - Tomcat Server Windows 8.1 VM

Firefox is not configured to use a proxy, its all in Vmware 
Workstation 10 using the Vmnet01 virtual network.


Firefox has three 401 responses with headers Authorization and 
WWW-Authenticate :-


1 :- Reponse WWW-Authenticate: Negotiate

2 :- Request Authorization: Negotiate 
YIIGUgYGKwYBBQUCoIIGRjCCBkKgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBgwEggYIYIIGBAYJKoZIhvcSAQICAQBuggXzMIIF76ADAgEFoQMCAQ6iBwMFACCjggR6YYIEdjCCBHKgAwIBBaEQGw5LRVJCVEVTVC5MT0NBTKIqMCigAwIBAqEhMB8bBEhUVFAbF3dpbi10YzAxLmtlcmJ0ZXN0LmxvY2Fso4IEKzCCBCegAwIBF6EDAgEDooIEGQSCBBVToJwn2tPBboTTk5BBzJktj/GIuSekyM94atYd2nmQZr+LRVHUS1CD27iufu9aGtRLNT2YStbH3VgBpxcB0mEdOGcqfwif2htDkbFbSr6bmvZLz7PDMZv0mpUw2jcLnuVYpJjcw0fygonPpLYNTKnwrJJQA7eYMqY5DWI2ntF5RACw0qHJrXY2yFBQ3GOo8+1PHz9WcuxmTdUsLgx9QbFvEjTdksor5xvsInRNWOdjwgObnnhzGEF2RbAyD3HYanU4pdK9QL7HIEL5AI61czl2RfgVzDIGokBlW3k6R7jEp6jUBOwBjTnJC8gZthlAfTIqRlyZOntbFeHboeNY6YYtFukdewgBSuFKRTPd7wv4cvSBrF+FsvwIM0wiy2Kkp6fvyh3O/fHRXSR5AaJvnbIj+XtIUX86K5TGG0GmA9hnLjt4sacfxxz05aqlpQ1ttPBt67MEMECQiZZB4Ck1BsMpLSf22tCSVUwZEZF0MdtKiQTe7U0GDOEcm5oZfhpn8ecDkEosinyk10jGFK1cyr23TcwIlLH6yC0YaksB19EAADSF9dQKbftRUVcTjUgOdGcf7eEcUdNcmYw/ftHsanMwZEat5lznurgVFDwa6rjxVoc+X/C6Dwl+ME/yEClpwn6bxxD
yCssxUgYsiRfWJGCr6EEPdWB5omQUf1o9ArvEbgtyS4kkHGLa3X5FeXctRwi2Yj/uLYnEOZHfkcoKk31FvdhSr92Kry4926hlS9ao4nyGS7ZVnvr1n8r5V6+D6UbYhUQgBvEaERgc8T822kiij1N/szQePAze4YWWTA0djryRSB0qqMGgBdtzg76+whlvjOkG0J4MjUbFy1iLvfOkIWXgHRChGeMCrphv64NmfgHQmOiYPdqtTgYlAvyW9riL1kci7Xz+D1XwfxJpdimsakfyRqpjIEkgU+QEN+aL8/1X8lRTu8uTepXVReBlSx2Am+DFgesBlkjWuYmIuj84mUH0Lcc7yHytOyfO5OJ4mI5O5YNkl167xMcI9akaH7LtS+c1OnfHwtlJsatLnOyLYwYP9KWpkh0i2d4DNV0EYs3B68UbsY3f4+bZcHW9SQ/PthGjzk5FTdOKh5dD0BLf1ADl+Rp5hegl0iGS6cVpZFnu8n3wPd2eenwQn0EDvyx3nuMyeETqqXEuLjTbqbMpzIxSxFl5s/1Nwaf4Up0a8wcEDNj3acnHicis8ELEORo+wtJnd0wyMIpfC+tFRsewhEHDttjWnqxkHbfpbOnChZkLOL04YoflhHK3ZrsBXk0Yu0udKIZBoJ7Pf5qiOdE36lEjAkWLB/2wVD+zvxfIKd7r9FSxAfYz0UsVYVyBX0RtF5GCpTPqLAk9ImL4xxpkijpUUwjlM9WylH8jafaHGwfmpUM9pIIBWjCCAVagAwIBF6KCAU0EggFJv04NvH3OA0+sXGdCWanthHZBM9DIq0AknWszbwm9z+7da/DThLEAnnozvO84tK/DD7fC/AnSWKXnqchILMdjPnZA5Bg3yjS4Y1rJFawc9fDNUmTCn4ILjjl6SSETMbJSFjzarv4wEfy5VU16DNBzWUxEJNH8PvsXTTfdzcwdsYnFwHGZbrcNxaJUtp3xpyoG/1EAgNk9i1UtewL1bHVkm 

muJXUXXetL7v4RzMuVD5q68q8nWDB1toKgcEjHEgEHWjODwSD/zoYwZrn1nCtnRm8aN9xKr097iK5K8ZUJKxWr4SlmAI6tZSyaVJGWJSzRvb47SZ9TVfk6Xft+vV+pVjxXdNAKIqHqA4tUfPCKgWff6iGmQI4fnJG5yYyyNFXOajz0qMYpfnbNLjc+nhsxjOUvZKOT4xTvhuOTCmdtabMybTVx4uNJEQ/4= 



Response WWW-Authenticate: Negotiate oRQwEqADCgEBoQsGCSqGSIb3EgECAg==

3 :- Request Authorization: Negotiate 

Re: Tomcat 7 (7.0.54) memory consuption is very high(3 times) than Tomcat 6 (6.0.28)

2015-03-24 Thread Terence M. Bandoian

On 3/23/2015 11:28 PM, Rahul Kumar Singh wrote:

Also interesting is cat /proc/PID/maps but here one would need to calculate 
sizes per line from the two hex addresses given at the start of each line. Something like:
cat /proc/PID/maps | perl -n -e '($a,$b)=split(/[- ]/);print hex($b)-hex($a),  
, $_;' | sort -n
(replace PID by the current Tomcat java process id).

Command: cat /proc/19487/maps | perl -n -e '($a,$b)=split(/[- ]/);print hex($b) -hex($a), 
 , $_;' |sort -n abc.txt

OUTPUT
0d4b8000-0e736000 rw-p 0d4b8000 00:00 0  [heap]
ff60-ffe0 ---p  00:00 0  
[vsyscall]
2aaab000-2aab3000 r--s 00061000 09:01 2519920
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/ext/gnome-java-bridge.jar
2aab3000-2aab5000 r--s 6000 09:01 1834753
/opt/tomcat/bin/bootstrap.jar
2aab5000-2aab6000 r--s 5000 09:01 1834758
/opt/tomcat/bin/commons-daemon.jar
2aab6000-2aab8000 r--s 8000 09:01 1834770
/opt/tomcat/bin/tomcat-juli.jar
2aab8000-2aac5000 r-xp  09:01 2519898
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libverify.so
2aac5000-2acc4000 ---p d000 09:01 2519898
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libverify.so
2acc4000-2acc6000 rw-p c000 09:01 2519898
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libverify.so
2acc6000-2acef000 r-xp  09:01 2519877
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libjava.so
2acef000-2aeee000 ---p 00029000 09:01 2519877
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libjava.so
2aeee000-2aef rw-p 00028000 09:01 2519877
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libjava.so
2aef-2aef1000 r--p 2aef 00:00 0
2aef1000-2aef2000 rw-p 2aef1000 00:00 0
2aef2000-2aefa000 rw-s  09:01 2056360
/tmp/hsperfdata_app/19487
2aefe000-2af08000 r-xp  09:01 261147 
/lib64/libnss_files-2.5.so
2af08000-2b107000 ---p a000 09:01 261147 
/lib64/libnss_files-2.5.so
2b107000-2b108000 r--p 9000 09:01 261147 
/lib64/libnss_files-2.5.so
2b108000-2b109000 rw-p a000 09:01 261147 
/lib64/libnss_files-2.5.so
2b109000-2b111000 r-xp  09:01 2519899
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libzip.so
2b111000-2b31 ---p 8000 09:01 2519899
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libzip.so
2b31-2b311000 rw-p 7000 09:01 2519899
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libzip.so
2b311000-2b771000 rwxp 2b311000 00:00 0
2b771000-2e311000 rw-p 2b771000 00:00 0
2e311000-2e323000 rw-p 2e311000 00:00 0
2e323000-2e3d1000 rw-p 2e323000 00:00 0
2e3d1000-2e3e rw-p 2e3d1000 00:00 0
2e3e-2e424000 rw-p 2e3e 00:00 0
2e424000-2e51f000 rw-p 2e424000 00:00 0
2e51f000-2f3cd000 rw-p 2e51f000 00:00 0
2f3cd000-2f60c000 rw-p 2f3cd000 00:00 0
2f60c000-2f6ec000 ---p 2f60c000 00:00 0
2f6ec000-2fba2000 rw-p 2f6ec000 00:00 0
2fba2000-2fc9e000 rw-p 2fba2000 00:00 0
2fc9e000-2aaab0b4d000 rw-p 2fc9e000 00:00 0
2aaab0b4d000-2aaab0b5c000 rw-p 2aaab0b4d000 00:00 0
2aaab0b5c000-2aaab0ba rw-p 2aaab0b5c000 00:00 0
2aaab0ba-2aaace81c000 rw-p 2aaab0ba 00:00 0
2aaace81c000-2aaace9d7000 r--s 01c8f000 09:01 2519963
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/rt.jar
2aaace9d7000-2aaad0cd4000 rw-p 2aaace9d7000 00:00 0
2aaad0cd4000-2aaad42a3000 r--p  09:01 2227921
/usr/lib/locale/locale-archive
2aaad42a3000-2aaad42b3000 r-xp  09:01 2519890
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libnio.so
2aaad42b3000-2aaad44b3000 ---p 0001 09:01 2519890
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libnio.so
2aaad44b3000-2aaad44b4000 rw-p 0001 09:01 2519890
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libnio.so
2aaad44b4000-2aaad44c9000 r-xp  09:01 2519889
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libnet.so
2aaad44c9000-2aaad46c9000 ---p 00015000 09:01 2519889
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.9.x86_64/jre/lib/amd64/libnet.so
2aaad46c9000-2aaad46ca000 rw-p 00015000 09:01 2519889

Re: login issue

2015-02-17 Thread Terence M. Bandoian

On 2/17/2015 9:51 AM, James McEvoy wrote:

Checked logs, added admin and manager to all needed files and added url so
it's ok for tomcat to use and still rejected when Logging in.
Stumped. I started and stopped it etc.



Hi, James-

You might try posting the new contents of tomcat-users.xml (with 
passwords obfuscated).


-Terence Bandoian




On Tuesday, February 17, 2015, James McEvoy tradingllc2...@gmail.com
wrote:


Ok if will check all

On Tuesday, February 17, 2015, John D. Ament johndam...@apache.org
javascript:_e(%7B%7D,'cvml','johndam...@apache.org'); wrote:


Check your logs for why.  Don't forget to include the manager-gui role in
the list of roles.

John

On Tue Feb 17 2015 at 8:15:45 AM James McEvoy tradingllc2...@gmail.com
wrote:


ok it wont take the shutdown command.

On Tue, Feb 17, 2015 at 6:59 AM, James McEvoy tradingllc2...@gmail.com

wrote:


couldnt screenshot so i just copied and pasted.

?xml version='1.0' encoding='utf-8'?
!--
   Licensed to the Apache Software Foundation (ASF) under one or more
   contributor license agreements.  See the NOTICE file distributed

with

   this work for additional information regarding copyright ownership.
   The ASF licenses this file to You under the Apache License, Version

2.0

   (the License); you may not use this file except in compliance with
   the License.  You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an AS IS BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or

implied.

   See the License for the specific language governing permissions and
   limitations under the License.
--
tomcat-users
   role rolename=tomcat /
   role rolename=role1 /
   user username=tomcat password=tomcat role=tomcat /
   user username=both password=tomcat role=tomcat,role1 /
   user username=role1 password=tomcat role=role1 /
/tomcat-users





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



Re: WorkManager replacement

2015-02-13 Thread Terence M. Bandoian

On 2/13/2015 8:52 AM, Kevin Hale Boyes wrote:

I'll look into the timers for sure.
I've also noticed that my application (lots of code) also uses Executors
and ExecutorService so I might do something there.

One of the things that WorkManager gave us, and we take advantage of, is a
callback handler that lets us know when the work was accepted for
processing and when it was complete.  I'll have to find replacements for
that feature.  Maybe that's easily done with Future's in the concurrency
framework.

Thanks for your help.
Kevin

On 13 February 2015 at 06:15, David kerber dcker...@verizon.net wrote:


On 2/13/2015 7:29 AM, Daniel Mikusa wrote:


On Thu, Feb 12, 2015 at 11:59 PM, Kevin Hale Boyes kcbo...@gmail.com
wrote:

  I currently have an application running on weblogic that I'm moving over

to
tomcat 8.
One of the things the application does is run background jobs using the
commonj WorkManager.  These jobs are managed by weblogic which seems to
be
the recommended practice.

What is the best/recommended way to run background jobs in Tomcat 8?



Personally I'd use Spring, which has a nice and simple way to schedule
tasks.  I'd also be using Spring for other things though and I'm not sure
I'd pull it in just for scheduled tasks.


I use java.util.timer for my scheduled jobs in tomcat.




A quick google search came up with this library.

 http://commonj.myfoo.de/

Haven't personally used it though.

I suppose another option would be to just use java.util.concurrent.

Dan




Thanks,
Kevin



I've used something similar to the following in the past:


public class AServletContextListener implements ServletContextListener
{

private ScheduledExecutorService executor;


/**
 * Constructs AServletContextListener object.
 */

public AServletContextListener()
{
}


/**
 * Invoked when context is initialized.
 *
 * @paramscetriggering ServletContextEvent
 */

public void contextInitialized( ServletContextEvent sce )
{
if ( executor == null )
{
executor = Executors.newSingleThreadScheduledExecutor();

Calendar firstRunTime = new GregorianCalendar();
firstRunTime.set( Calendar.HOUR_OF_DAY, 12 );
firstRunTime.set( Calendar.MINUTE, 0 );
firstRunTime.set( Calendar.SECOND, 0 );
firstRunTime.set( Calendar.MILLISECOND, 0 );

executor.scheduleAtFixedRate(
new ARunnable(),
firstRunTime.getTimeInMillis() - 
System.currentTimeMillis(),

1000 * 60 * 60 * 24,
TimeUnit.MILLISECONDS );
}
}


/**
 * Invoked when context is destroyed.
 *
 * @paramscetriggering ServletContextEvent
 */

public void contextDestroyed( ServletContextEvent sce )
{
if ( executor != null )
{
boolean isTerminated = false;

executor.shutdown();

do
{
try
{
isTerminated = executor.awaitTermination(
1, TimeUnit.SECONDS );
}
catch ( InterruptedException ignore )
{
}
}
while ( !isTerminated );

executor = null;

Thread.yield();
}
}

}


It's simple, not very much code and gets the job done.  The call to 
Thread.yield was added to eliminate an error message in the Tomcat logs.


-Terence Bandoian


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



Re: tomcat severe error when shutting down service but startup is clean

2015-02-13 Thread Terence M. Bandoian

On 2/13/2015 11:21 AM, David kerber wrote:

On 2/13/2015 11:54 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,


...


public static void unRegisterDrivers() { try { for (
EnumerationDriver drivers = DriverManager.getDrivers();
drivers.hasMoreElements(); ) { DriverManager.deregisterDriver(
drivers.nextElement() ); } } catch ( Exception e ) { /* log
the exception */ } }


This is likely to over-reach in many scenarios. YMMV.

Also, Tomcat already de-registers drivers for you. So, this
probably isn't really changing anything.


We manage the pooling in our application, and don't use any of
TC's connection pooling.  This is largely because several years ago
(long enough ago that the then-current version of TC was 5.5.25)
the app was moved from another servlet container that either didn't
have pooling, or it was harder to use than it was to write out own.
I wasn't in on the initial development, but did the port to TC.
And at the time I did the port, I had no idea about TC's connection
pooling, so continued with our own pooling implementation.

Until I did this, I could not get rid of the memory leak warnings.
If there is another way, I couldn't find it at the time I was
messing with it...


I'm not sure at what point Tomcat started de-registering drivers. When
it de-registers a driver, it gives you a warning. By you doing it
yourself, you are avoiding the warning, of course.

But if you de-register all drivers, you are also de-registering any
drivers that were registered by different web applications, Tomcat's
connection-pool, etc. It would be better to only de-register the
driver(s) you actually registered in the first place.

I haven't researched such things, but a reasonable way might be to do
something like this:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
for(Driver driver : DriverManager.getDrivers())
   if(cl.equals(driver.getClass().getClassLoader()))
 DriverManager.deregisterDriver(driver);

This way, you only remove drivers you load yourself. Alternatively,
you probably already know which drivers you have explicitly loaded, so
you could explicitly unload them instead of flushing the whole
DriverManager.

Note: I have no idea if Driver objects get the proper ClassLoader
assigned, but it's worth a try to get a bit more safety.

If your web application is the only one loaded, feel free to wipe-out
the DriverManager like that. But, if you need to operate in a shared
environment, your technique above might negatively impact other code
that relies on its driver not being forcibly un-loaded out from under 
it.


Thanks for the suggestions, Chris!  The way we operate our environment 
currently there's no danger of killing another app, but I'll look into 
your suggestion for future reference.  I'm always open to suggestions 
on ways to improve my coding.



Something similar to the following worked for me:

public class DbDriver
{
private static Driver jdbcDriver = null;

protected static void loadDriver()
throws ClassNotFoundException, SQLException
{
if ( jdbcDriver == null )
{
synchronized ( DbDriver.class )
{
if ( jdbcDriver == null )
{
Class.forName( com.mysql.jdbc.Driver );

jdbcDriver = DriverManager.getDriver(
jdbc:mysql://127.0.0.1/ );
}
}
}
}

protected static synchronized void deregisterDriver()
throws SQLException
{
if ( jdbcDriver != null )
{
DriverManager.deregisterDriver( jdbcDriver );

jdbcDriver = null;
}
}
}

-Terence Bandoian



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



RE: tomcat errors

2015-02-12 Thread Terence M. Bandoian

On 2/11/2015 7:53 AM, Wirth, Kevin wrote:

The catalina log and the err logs are being written too

-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Wednesday, February 11, 2015 6:28 AM
To: Tomcat Users List
Subject: Re: tomcat errors

2015-02-10 22:45 GMT+03:00 Wirth, Kevinkwi...@astoriabank.com:

Yes, that is the log I am looking at and it is blank.


What about the other log files?



Look for anything in the logs/ directory. In a default configuration, the logs 
for your application would probably have gone to localhost-*.log.


Are logs being written (does the hard drive has free space so that logs can be 
written)?

There have to be some previous error.



In your first post, the error message indicated that a context could not 
be started because of a previous error.  That previous error has to 
be somewhere.  It might very well appear earlier in the same log.


-Terence Bandoian


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



Re: How-to disable SSL V3 on Tomcat 6.0.18.0

2015-01-29 Thread Terence M. Bandoian

On 1/29/2015 10:02 AM, Jammy Chen wrote:

Hello Chuck,

Thanks for replying, I understood this is old, our product has already
upgraded to latest version, but somehow, some of our users are still in
such old stage, they do not plan uptake now but they want disable SSL V3 as
everybody know this is big security vulnerability.


*so now the important thing is how I can disable SSL V3 on Tomcat 6.0.18.0?
I cannot find the solution*

Jammy

2015-01-29 22:00 GMT+08:00 Caldarale, Charles R chuck.caldar...@unisys.com
:


From: Jammy Chen [mailto:jamm...@gmail.com]
Subject: How-to disable SSL V3 on Tomcat 6.0.18.0
Do everybody knows how-to disable SSL v3 in older tomcat version
Server version: Apache Tomcat/6.0.18
Server built:   Jul 22 2008 02:00:36

Yes - move up to a current level and read the docs.

Seriously, if you're using a Tomcat of that vintage (this one is more than
6.5 years old), you have a lot more security issues to worry about than
SSLv3.  It's irresponsible not to upgrade.


OS Name:Windows 2003

A few months from end-of-life.


JVM Version:1.6.0-b105

Two years past end-of-life.

Is there a pattern here?

  - Chuck



Hi, Jammy-

I'd suggest downloading Tomcat 6.0.18 which includes the then-current 
documentation.


-Terence Bandoian


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



Re: [OT] Tomcat 8 encoding issues: unable to change the default encoding iso-8859-1 to utf-8 in http header

2015-01-26 Thread Terence M. Bandoian

On 1/25/2015 4:29 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/24/15 7:52 AM, André Warnier wrote:

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

André,


...


Morality : in web applications, always specify the
content-type (and character set, if applicable) of what you are
returning.

To André: the word you are looking for is Moral, not
Morality. A moral is the essential message of a story, while
morality is being able to tell the difference between right and
wrong. ;)


Thanks for the vocabulary note.  I my defense, I would say that
this family of English terms is a bit confusing, for a native
French-speaker.

Oh, English is a cluster-@#$*)% because the sentence structure is
insane and the vocabulary has been robbed from every other language in
history. I don't envy anyone trying to learn English.. it must seem to
chaotic compared to German or Latin-based languages (both of which I
have studied, and they have a certain beautiful order to them ... most
of the time).

You usually have impeccable English (better than most Americans, at
least), which is why I went ahead and gave you the short lesson.


There are many such things between different - but related -
languages, some of them often leading to amusing situations.  For
example, the word in spanish for suffering from a cold is
constipado, which is very close to the french word for being
incapable to go to the toilet (constipé).

Hah. I would have assumed both of those words were the latter
(gastrointestinal distress).


And the English adjective embarassed (also imported from the
French embarassé(e), and with the same meaning), is very close to
the Spanish embarassada, which means pregnant.

This all just in case someone was wondering about my interest in
character set issues on the WWW..

Just don't be embarrassed. Of pregnant. Or whatever. :)

- -chris



embarazada

-Terence Bandoian


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



Re: JSp dynamic include in tomcat 8.0.15

2015-01-26 Thread Terence M. Bandoian

On 1/25/2015 4:23 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Srikanth,

On 1/24/15 12:03 AM, Srikanth Hugar wrote:

When i include jsp:include page=/WEB-INF//countries.jsp
/

It does not work in tomcat 8.0.15.

I think there are too many dots in there. It that just an example?

What do you mean it does not work?


and my included jsp file contents are something like :

div class=txt form:select path=country form:option
value=US label=US - UNITED STATES OF AMERICA /
...



/form:select

/div


What could be the problem?

That depends on what happens when you try the above.

I'm not a JSP expert, but you might need to use %@ include instead
of jsp:include if you want to include files from within /WEB-INF/.

- -chris



From the JavaServer Pages Specification:

The %@ include file=... % directive is processed at translation time.  
The included content is parsed by the JSP container.  Only static 
content may be included.  The file attribute is interpreted relative to 
the current JSP file.


The jsp:include page=... / action is processed at request time.  The 
included content is not parsed.  Static and dynamic content may be 
included.  The page attribute is interpreted relative to the current JSP 
page.


-Terence Bandoian


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



Re: AJP connector address vs. IPv4/6

2015-01-24 Thread Terence M. Bandoian

On 1/23/2015 3:05 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 1/23/15 3:35 PM, André Warnier wrote:

Jess Holle wrote:

It seems that
java.net.InetAddress.getLoopbackAddress().getHostAddress() should
give the right answer -- if one is running with Java 7.

That said, is there a value that can be used for AJP's address
attribute that simply does the right thing here?

On 1/23/2015 1:38 PM, Jess Holle wrote:

I'd like to set the address attribute on the AJP connector
when deploying Tomcat to only allow loopback connections.

But I want to do so in a general way that works for:

* IPv4 * IPv4 + IPv6 mixed/dual stack * IPv6 (pure)

Is there any such option?  The documentation speaks of setting
127.0.0.1, yet I see indications that this won't fly in a pure
IPv6 world.  If a single value won't work, is there any good
way to detect which stacks are available via Java APIs during
deployment?


If only one address per Connector can be specified, can you not
just use 2 Connectors, one for each ? They should not conflict.

That should definitely work (address=127.0.0.1 and address=::) but
one connector might be nice.

Maybe Tomcat could detect some magic value that is invalid for an
address (like loopback) and then use
InetAddress.getLoopbackAddress() instead of a traditional address
lookup/resolution.

- -chris




localhost might be a good choice.

-Terence Bandoian


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



Static files with default servlet in tomcat 8.0.9

2015-01-12 Thread Terence M. Bandoian

Please see my comments inline below.


On 1/12/2015 8:55 AM, Srikanth Hugar wrote:

Hello,

I am trying to configure static files with default servlet in tomcat
8.0.9 but could not succeed.

My directory structure in deployed webapp is:

- WEB-INF
- static
  -css
  -images
  -js
- META-INF

and* web.xml* configuration using default servlet is :

   !-- static URLs --
 servlet-mapping
 servlet-namedefault/servlet-name
 url-pattern/res/*/url-pattern
 /servlet-mapping



Mappings for the default servlet should already be defined - check 
conf/web.xml.





But when i make request from my page with URL it fails with 404.
http://SUB.DOMAIN.COM/myapp/*res/static/*js/imports/jquerymin.js



Based on the directory structure above and assuming a context path of 
myapp, the URL should be something like:


http://SUB.DOMAIN.COM/myapp/static/js/imports/jquerymin.js

The folder res does not exist.

-Terence Bandoian




What could be the problem?
How can i make it work?


I tried to find information from web, but could not help.

Thanks.



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



Re: Tomcat 8, Apache 2.4, Tomcat Connector 1.2.40, Windows 7 home basic issue

2015-01-07 Thread Terence M. Bandoian

Please see inline comments from previous message.

-Terence Bandoian


On 1/2/2015 9:45 PM, Terence M. Bandoian wrote:

On 1/1/2015 9:20 AM, Sandip Gaikwad wrote:

Hi,

Following are entries in files. Please let me know what is going wrong.

*workers.properties*
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.connection_pool_size=10
worker.worker1.connection_pool_timeout=600
worker.worker1.socket_keepalive=true
worker.worker1.socket_timeout=300


*httpd.conf*
LoadModule jk_module C:/Apache24/modules/mod_jk.so
JkWorkersFile C:/tomcat-connectors-1.2.40-src/conf/workers.properties
JkLogFile C:/Apache24/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat %w %V %T
JkMount /jenkins/* worker1

*server.xml*
?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN
  Listener className=org.apache.jk.config.ApacheConfig 
modJk=C:/Apache24/modules/mod_jk.so/
  Listener 
className=org.apache.catalina.startup.VersionLoggerListener /
  Listener className=org.apache.catalina.core.AprLifecycleListener 
SSLEngine=on /
  Listener 
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
  Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener 
/
  Listener 
className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / 



  GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources

  Service name=Catalina

Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /



If you don't want to allow direct access to Tomcat, the Connector 
above should be removed.




Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /



The address attribute should probably be set on the Connector above.  
Setting it 127.0.0.1 (address=127.0.0.1) will limit access to the 
local host.


-Terence Bandoian



Engine name=Catalina defaultHost=localhost
  Realm className=org.apache.catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/
  /Realm

  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
Listener className=org.apache.jk.config.ApacheConfig 
modJk=C:/Apache24/modules/mod_jk.so/
Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs

   prefix=localhost_access_log suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /
  /Host
/Engine
  /Service
/Server

Thanks,
Sandip


On Thu, Jan 1, 2015 at 7:45 PM, Christopher Schultz 
ch...@christopherschultz.net mailto:ch...@christopherschultz.net 
wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sandip,

On 1/1/15 12:19 AM, Sandip Gaikwad wrote:
 Could you please let me know how to block direct access to tomcat
 and allow access through apache http server only?

 I used http://

http://www.slideshare.net/mohanraj_nagasamy/integrating-tomcat-and-apache-on-windows-presentation


for reference.

tl;dr

 What indicates that each request is coming from apache httpd only?

Nothing, really. There are ways to determine this, but you are 
better

off solving the root problem.

 Example: i have added following code in httpd.conf # Send
 everything for context /example1 to worker named worker1 (ajp13)
 JkMount /example1/* worker1

 in tomcat i have two apps example1 and example2

 I am expecting to access only http://localhost/example1 . But i 
can

 access http://localhost/example2 as well.

 How can i stop http://localhost/example2 from being accessed?

Only one process can bind to a single interface+port, so you need to
figure out whether Tomcat or httpd is using port 80.

If httpd is bound to port 80, then the only reasons why a request to
/example2 would hit your application are:

   a) You have a JkMount somewhere for that
   b) You have made your DocumentRoot = appbase

The first is easy to fix: just remove that JkMount.
The second is a horrible security problem that you'll need to fix
immediately.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUpVaXAAoJEBzwKT+lPKRYY5AQAJ6+2NAhVtCWl1KMSQj2FGr8
TMh/cpFAUiFY8NYbxLhPLZnELf/PhoCZlBAHnUJN7j+ozr5YbjbBW7sVJ9kI3yu8
W1lB5zlxZKuVGBp3+GZsMdQcMDr/tg4Jkr8/TFKqUZOo5RPeTVoXxy+azdCNyMuy
BdogSIpqpxc1k6r1lQOGljiKzXiZJDdpkJwDau1mnzY8eO54pxZWHIJI63c4gu5y

Re: Tomcat 8, Apache 2.4, Tomcat Connector 1.2.40, Windows 7 home basic issue

2015-01-02 Thread Terence M. Bandoian

On 1/1/2015 9:20 AM, Sandip Gaikwad wrote:

Hi,

Following are entries in files. Please let me know what is going wrong.

*workers.properties*
worker.list=worker1
# Set properties for worker1 (ajp13)
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8009
worker.worker1.connection_pool_size=10
worker.worker1.connection_pool_timeout=600
worker.worker1.socket_keepalive=true
worker.worker1.socket_timeout=300


*httpd.conf*
LoadModule jk_module C:/Apache24/modules/mod_jk.so
JkWorkersFile C:/tomcat-connectors-1.2.40-src/conf/workers.properties
JkLogFile C:/Apache24/logs/mod_jk.log
JkLogLevel info
JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat %w %V %T
JkMount /jenkins/* worker1

*server.xml*
?xml version='1.0' encoding='utf-8'?
Server port=8005 shutdown=SHUTDOWN
  Listener className=org.apache.jk.config.ApacheConfig 
modJk=C:/Apache24/modules/mod_jk.so/
  Listener 
className=org.apache.catalina.startup.VersionLoggerListener /
  Listener className=org.apache.catalina.core.AprLifecycleListener 
SSLEngine=on /
  Listener 
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /
  Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /
  Listener 
className=org.apache.catalina.core.ThreadLocalLeakPreventionListener /


  GlobalNamingResources
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources

  Service name=Catalina

Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /



If you don't want to allow direct access to Tomcat, the Connector above 
should be removed.




Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /



The address attribute should probably be set on the Connector above.  
Setting it 127.0.0.1 (address=127.0.0.1) will limit access to the 
local host.


-Terence Bandoian



Engine name=Catalina defaultHost=localhost
  Realm className=org.apache.catalina.realm.LockOutRealm
Realm className=org.apache.catalina.realm.UserDatabaseRealm
   resourceName=UserDatabase/
  /Realm

  Host name=localhost  appBase=webapps
unpackWARs=true autoDeploy=true
Listener className=org.apache.jk.config.ApacheConfig 
modJk=C:/Apache24/modules/mod_jk.so/
Valve className=org.apache.catalina.valves.AccessLogValve 
directory=logs

   prefix=localhost_access_log suffix=.txt
   pattern=%h %l %u %t quot;%rquot; %s %b /
  /Host
/Engine
  /Service
/Server

Thanks,
Sandip


On Thu, Jan 1, 2015 at 7:45 PM, Christopher Schultz 
ch...@christopherschultz.net mailto:ch...@christopherschultz.net 
wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sandip,

On 1/1/15 12:19 AM, Sandip Gaikwad wrote:
 Could you please let me know how to block direct access to tomcat
 and allow access through apache http server only?

 I used http://


http://www.slideshare.net/mohanraj_nagasamy/integrating-tomcat-and-apache-on-windows-presentation


for reference.

tl;dr

 What indicates that each request is coming from apache httpd only?

Nothing, really. There are ways to determine this, but you are better
off solving the root problem.

 Example: i have added following code in httpd.conf # Send
 everything for context /example1 to worker named worker1 (ajp13)
 JkMount /example1/* worker1

 in tomcat i have two apps example1 and example2

 I am expecting to access only http://localhost/example1 . But i can
 access http://localhost/example2 as well.

 How can i stop http://localhost/example2 from being accessed?

Only one process can bind to a single interface+port, so you need to
figure out whether Tomcat or httpd is using port 80.

If httpd is bound to port 80, then the only reasons why a request to
/example2 would hit your application are:

   a) You have a JkMount somewhere for that
   b) You have made your DocumentRoot = appbase

The first is easy to fix: just remove that JkMount.
The second is a horrible security problem that you'll need to fix
immediately.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUpVaXAAoJEBzwKT+lPKRYY5AQAJ6+2NAhVtCWl1KMSQj2FGr8
TMh/cpFAUiFY8NYbxLhPLZnELf/PhoCZlBAHnUJN7j+ozr5YbjbBW7sVJ9kI3yu8
W1lB5zlxZKuVGBp3+GZsMdQcMDr/tg4Jkr8/TFKqUZOo5RPeTVoXxy+azdCNyMuy
BdogSIpqpxc1k6r1lQOGljiKzXiZJDdpkJwDau1mnzY8eO54pxZWHIJI63c4gu5y
akinaEncJDzI5dFwAQWiL/C+CtO8ujiUePH+FfpwfzoQozqIa+hpCaipwtOdc+0Z

Re: Initialise application once

2014-12-22 Thread Terence M. Bandoian

On 12/21/2014 9:14 AM, Fabio Ricci wrote:

Yes that made it

THANK YOU very much!!!
Grazie mille!

Cheers
Fabio


Am 21.12.14 um 14:10 schrieb Alessandro Manzoni:

Il 21.12.2014 13.38, Fabio Ricci ha scritto:

Dear community

I developed a tomcat JSP servlet which - say - instantiates a class, 
work with that class and gives some output back to the calling user 
in the browser.


My point is instantiating the class ***once*** for every requests 
coming after this instantiation. The reason is: the class loads 
several components into memory and I would like not to do this at 
every call of this JSP servlet but just once.


Where shell I put the initializing code for the heavy components? 
Is this possible?


Thank you very much in advance!
Fabio

Try putting an attribute inside the servlet contex in a lazy way, 
that will be in the scope of the whole application inside the same 
VM.E.g.:

Object grosso = getServletContext().getAttribute(GROSSO);
if (grosso == null) {
   grosso = new Grosso();
   getServletContext().setAttribute(GROSSO, grosso);
}
If you want to limit the scope to a single session, put the same as a 
session attribute.



You could also use a singleton that initializes itself in the same way.  
Either way, the object and initialization should be thread safe.


Happy Holidays!

-Terence Bandoian


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



Re: REST call failure on newer tomcat version/update

2014-12-22 Thread Terence M. Bandoian

On 12/22/2014 6:02 AM, Konstantin Kolinko wrote:

2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com:

Hello,

We had a gwt app deployed and working with tomcat 7_42 and tried it
recently in several configurations (Windows/Linux) with the latest update
of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
calls succeed but this particular one appears to get an http code of 200
but doesn't return any data (but it should) - and so the app never
proceeds. There's no message, exception, etc - so the app just sits there.

In running this on several clients (Firefox, Chrome, RestClient for FF,
etc), I *have* received a couple messages on that call (in certain
situations) such as...

Error Code: 502 Proxy Error. A software error occurred for a Windows
Internet extension application that is required for the current operation.

and

Error 415 Unsupported Media Type

Does anyone have an idea what this might be? Why it changed?  If I swap out
the latest version for 41 or 42, and change nothing else, it works fine.
Can't find anything in docs or searches online.


What is your configuration?

I guess that those 500 and 415 responses are not from Tomcat. Are they
from IIS? Is that one up-to-date?

Do you have access log configured in Tomcat? Are those requests
mentioned in Tomcat access log?

Does the issue happen randomly? Can you reproduce it?


Best regards,
Konstantin Kolinko



Which app just sits there?  Whichever it is, shouldn't the status and 
data in the response be validated?  Not receiving the data expected with 
a given status would, in my mind, constitute an error.


-Terence Bandoian



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



My problem: I cannot successfully get or set a session attribute from a JSP file.

2014-12-08 Thread Terence M. Bandoian

On 12/6/2014 3:19 PM, Jim Anderson wrote:


Hi to all,

I am currently developing some server side JSP code. By and large, 
things are progressing and working well. I have gotten half way decent 
at debugging my java/javascript/jquery/jsp/HTML source code, but I 
have run into a problem in JSP where the code does not work, but I 
have found no clues as to why it is not working.


The environment that I am working in is Tomcat 7.0.54 and I am using 
java 1.8 and jquery 1.7.2.


What I am trying to do:

I have html code with an embedded javascript that runs jquery code. 
The jquery code being run makes an ajax call to a JSP file on the 
server side, which I will call s.jsp. This file is a very simple file 
whose sole function is to take a registration name and query an SQL 
database to see if the name has already been used at the web site. The 
registration name is passed with a method call that looks like this:


regName = request.getParameter(registrationName); [item 1]

This all works fine for me. So far so good. If the registration name 
is good, the state of my application logic changes. I guess there are 
multiple ways to store state, but I have chosen to store the state as 
a session variable.  I searched the net and found an example of JSP 
code that uses the session object to store information as an attribute 
with a statement that looks something like:


session.setAttribute(logicState,nameValidated); [item 2]

I tried adding this line and when I now push the submit button of my 
HTML form, which calls s.jsp as an action, the application hangs (in 
firefox). I receive no error messages anywhere. Usually, when I add 
bad code in s.jsp I will get a stacktrace from firefox or error 
messages in the firefox debug console, or both. Or I will error 
message in my own homegrown debug code, but that does not happen. I 
know that my home grown code does not get called, so I can infer that 
the call to s.jsp is never made, but I cannot be 100% certain of this. 
I also checked my tomcat/logs directory and there was nothing in the 
log files that I would not expect.


So my first question is:  Can I simply add item 2, above, to my jsp 
file and expect that tomcat will recognize that I am referencing the 
session object?  In s.jsp, item 1, above, references the request 
object and tomcat handles that and I am expecting that it will also 
hand my reference to the session object.


My second question is more general. My code is not working and there 
are no error messages. Can anyone speculate why this would be the 
case?  Is there any   place else I should be looking for error messages?


Jim A.




Hi, Jim-

You should be able to see in Firebug or the Network tab of the Firefox 
developer's tools whether or not the request was actually sent by the 
browser.


-Terence Bandoian


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



Re: jsp page on Tomcat non loading css

2014-11-08 Thread Terence M. Bandoian

On 11/7/2014 7:55 PM, Daniel Baktiar wrote:

Hi Alessandro,

Is there any servlet filter running which modifies the Content-Type
headers?
Look at the web.xml for filter/ tag.

Daniel Baktiar

On Thu, Nov 6, 2014 at 7:04 PM, Alessandro Panzeri 
alessandro.panzer...@gmail.com wrote:


I deployed a war on Tomcat 7 to serve a jsp page.

In the jsp page I put this css tag:

link href=../css/new_style.css rel=stylesheet type=text/css/

Also, at the beginning of the jsp page I put this:

%@ page contentType=text/html;charset=utf-8 %

However when I contact via browser such jsp page, the css is NOT loaded and
I found that the reason is (returned by Google Chrome inspecting the page):

Resource interpreted as Stylesheet but transferred with MIME type
text/plain.

I can't figure out what to modify...any advice?



Hi, Alessandro-

Something doesn't seem right to me.

What is the URL you use to access the JSP page?
What is the path name of your application directory?
What is the path name of the CSS directory?

-Terence Bandoian


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



Re: Security Best Practices on Windows Service

2014-11-07 Thread Terence M. Bandoian

On 11/5/2014 1:34 PM, Igal @ getRailo.org wrote:

hi,

what are the security best practices for running Tomcat as a Windows
Service?

is the local system account safe or am I better off creating a new user
and giving it write permissions only to the Tomcat runtime folders and
read permissions to the web contents folder?

TIA




Hi, Igal-

You might consider enabling the Java Security Manager.

-Terence Bandoian


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



Re: From HTTP to HTTPS request.getHeader(referer)

2014-11-04 Thread Terence M. Bandoian

On 11/4/2014 4:46 AM, Léa Massiot wrote:

Hi,


Terence M.  Bandoian wrote:
I'm not sure how you're using it but it's worth pointing out that
response.sendRedirect Sends a temporary redirect response to the
client...  The client (browser) must then send another request to the
server before any additional processing takes place.  In contrast,
pageContext.forward takes place entirely on the server.

I didn't know that.
I thought there was one HTTP(S) request and one HTTP(S) response only.
How can the mechanism you describe above affect the use of HTTPS for a
webapp with the CONFIDENTIAL security constraint on a standalone Tomcat
server?

I'm using sendRedirect() in a very straightforward way I think.
I use some sort of pipelines for a subset S of JSPs in the webapp:
1) Given a JSP s in S, it contains a form with an action attribute
mapped via web.xml to a servlet L.
2) The servlet L  implements either a doPost() or (rarely) a doGet() method.
3) Given what was submitted via the form, work is performed in the
servlet.
4) When the servlet work is done and depending on the result (success 1,
..., success n / error 1, ..., error n), the servlet redirects towards the
next JSP using the method sendRedirect().
Is there a temporary redirect response to the client in that case?
Is this behavior documented somewhere? I could totally benefit from a good
documentation...

Best regards.



Hi, Léa-

You can find information about HttpServletResponse and PageContext in 
the Java Servlet and JavaServer Pages specifications which are available 
on the Oracle web site.  JavaDocs are also available online.  Be sure to 
reference the appropriate versions of the specs and JavaDocs for your 
application.  Links to copies of the JavaDocs are available on the 
Tomcat documentation pages:


Tomcat 7 - https://tomcat.apache.org/tomcat-7.0-doc/index.html
Tomcat 8 - https://tomcat.apache.org/tomcat-8.0-doc/index.html

The links are labeled Servlet JavaDocs and JSP 2.x JavaDocs in the 
Reference section on the left.


-Terence Bandoian


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



Re: From HTTP to HTTPS request.getHeader(referer)

2014-11-03 Thread Terence M. Bandoian

On 11/2/2014 11:34 AM, Léa Massiot wrote:

Hi again.
It looks like sendRedirect() is working if I pass it a HTTPS URL as an
argument:

-
String s_prov =
request.getScheme() + ://
+ request.getServerName()
+ request.getContextPath() + /
+ example1.jsp;
 
response.sendRedirect(s_prov);

-

Nota: in my case, request.getScheme() is equal to https.

I think I'm going back to sendRedirect()...
Snif :'/, it's a lot of matches to replace back (from forward() to
sendRedirect())...

Best regards.



Hi, Léa-

I'm not sure how you're using it but it's worth pointing out that 
response.sendRedirect Sends a temporary redirect response to the 
client...  The client (browser) must then send another request to the 
server before any additional processing takes place.  In contrast, 
pageContext.forward takes place entirely on the server.


-Terence Bandoian


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



Re: From HTTP to HTTPS request.getHeader(referer)

2014-11-01 Thread Terence M. Bandoian

On 10/31/2014 11:18 AM, Mark Eggers wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/31/2014 5:06 AM, Léa Massiot wrote:

Hello and thank you for reading my post.

I'm trying to make a webapp work with HTTPS. It was working
properly with HTTP. Below is the problem I have.

Inside a servlet, in its doPost() method, to check whether the
incoming JSP is example1.jsp or example2.jsp, I am using the
following piece of code:
---
s_referer = request.getHeader(referer);

if(s_referer.contains(example1.jsp) == true) { b_jspReferer1 =
true; } if(s_referer.contains(example2.jsp) == true) {
b_jspReferer2 = true; }
---

In example1.jsp and example2.jsp there is a form element
which action attribute is set to do_example:
--- form
method=post action=do_example [...] /form
---

Now that I'm using HTTPS, s_referer is always equal to
do_example in the servlet. Before, it used to be either
example1.jsp in case the incoming JSP was example1.jsp and
example2.jsp in case the incoming JSP was example2.jsp.

I don't know how to correct my code to be able to discriminate
between the two JSPs. Can you please help me?

I apologize in advance for the barbaric expression incoming JSP.
I hope my point is understandable despite unfortunate expression.

Best regards.



-- View this message in context:
http://tomcat.10.x6.nabble.com/From-HTTP-to-HTTPS-request-getHeader-referer-tp5024782.html



Sent from the Tomcat - User mailing list archive at Nabble.com.

Times the referer will be empty:

1. entered the site URL in browser address bar itself.
2. visited the site by a browser-maintained bookmark.
3. visited the site as first page in the window/tab.
4. switched from a https URL to a http URL.
5. switched from a https URL to a different https URL.
6. has security software installed (antivirus/firewall/etc) which
strips the
referrer from all requests.
7. is behind a proxy which strips the referrer from all requests.
8. visited the site programmatically (like, curl) without setting the
referrer header (searchbots!).

Have you looked in various tools on the browser (developer tools on
Chrome, Tamper on Firefox, Fiddler on IE) to see if the referer is
being set?

. . . just my two cents
/mde/




Hi, Léa-

Rather than relying on REFERER, you might consider using different 
action attributes in example1.jsp and example2.jsp.  The targets could 
be minimal servlets that set a parameter and forward to do_example.


Another approach would be to use hidden input elements in your forms 
(e.g. input type=hidden name=formId value=1).


-Terence Bandoian


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



Re: HTTPS / URLs with no port number / Tomcat only

2014-10-29 Thread Terence M. Bandoian

On 10/28/2014 5:59 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Terence,

On 10/28/14 5:49 PM, Terence M. Bandoian wrote:

On 10/28/2014 8:55 AM, Léa Massiot wrote:

Christopher Schultz-2 wrote

A bit of warning: when modifying iptables, you need to be very
careful that you don't wipe-out any rules that allow you to
gain remote access to the server. For instance, if you have a
default rule to DROP all packets and an exception that allows
port 22 (ssh) traffic, then flushing all the rules in a table
can make it impossible for you to revert the change without
remote-rebooting (or, worse yet, paying someone to walk into
the cage and push the reset button).

Yes right, fortunately I wasn't working on a remote machine.

On Debian Wheezy, the following set of commands actually disables
the firewall:
--- iptables
-F iptables -X iptables -t nat -F iptables -t nat -X iptables -t
mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables
-P OUTPUT ACCEPT iptables -P FORWARD ACCEPT
---

Best regards.


Hi, Léa-

Ideally, I think you'd want to permanently modify the iptables
rules to enable traffic over the desired port.  Doing so would keep
the existing safety measures in place and all of the rules would
survive a reboot. However, if you just want to temporarily disable
iptables, I believe

service iptables stop

would do so.

Debian Wheezy doesn't use service, instead it still uses
/etc/init.d. Oddly enough, there is no /etc/init.d/iptables script for
Debian[1]. We deploy on Debian in most environments and have simply
rolled our own iptables script that runs on boot.



Nasty.  I like service interface available on Red Hat and CentOS. On 
Debian/Ubuntu, it looks like the ufw package might be helpful.


-Terence





Permanently disabling iptables would require a little more work as,
in my experience, it is typically configured to start when the
system is booted.

Yes, and it's not really a good idea for production: you want your
firewall configured properly instead of in by any means necessary
mode. Configuring a server in anger usually ends up with an insecure
configuration.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJUUB/IAAoJEBzwKT+lPKRYN64P/2JjyqfMDQMSp8OopxpQjF4K
cSOrJ1YbYRkw79gYJpg5XNP5DcAYu8INcYsZ8r685aLHgkCl8a7IWC0gKJQX2TfO
QGy5pN9NvZrO+U+ont+9egEFcHNKqWMy522CTkpIp5tKLazG2iSjEw0kGePBftOp
UETb82wzy1EfiBDArQSzMfLgxVXhB5bPUJmdV2DzEN0m6fuF8oaWmqQNy06+L//V
ESieL0ovf9dRQFde8J4fxDT4b36l/yMjNSHvrKQMsiHfYiq2iqfA1xZUYv+hQtUh
S+Ezs/sIu3CnYqK+5mPX/+ET333DNXLz4IRaFpHlnI0Z2xuPaG5Gf6Dd2SUz5zxD
ag/u552Uo7KAYdp/17bifktpNJgRRgx0O6Zt0mr3+imFwQg6Ve5pMo/F59AepYtB
9awhri3lCw1urNLOrLOTwWZDGij1DtUlAbfcfKZ58kU2Iadb0h5mgos5NjKkljNv
x3a8IDqg8R8dB6A0I0ZjjOJH0xlIvH3hFh1gn9t7Wd5Wd61jtH7cpVGVRVW79JY/
qsjRGqUw6LtF1xYdYVsbfaRQpEbvz5TCBc/TBJXztszC0+f1akQZL3uBByxrlUZL
aukqEmxgTK9/PFaLtb7xM8JryNfwog9ETXmhx1dbKBr58GoOWAMN3OSd7mgKVkXV
J/GmKKtJ+2AKE2aCaVMt
=ZYjC
-END PGP SIGNATURE-




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



Re: How to access Sessions outside of class

2014-10-28 Thread Terence M. Bandoian

On 10/28/2014 9:36 AM, Jason Ricles wrote:

Thanks Tim,

That seems like the way to go. IT avoids us having to write our own
protocols and everything and instead just code the logic for what action to
take when a certain message is received.



Hi, Jason-

RMI seems reasonable if foo and bar might end up on different servers.  
However, if they will always reside on the same server, why not execute 
foo from within the web application?  If you're polling, scheduling 
background threads is fairly straightforward.


-Terence Bandoian




On Tue, Oct 28, 2014 at 10:27 AM, Tim Watts t...@cliftonfarm.org wrote:


Any IPC that you have to write from scratch is going have a not
insignificant level of complexity whether it's raw sockets, pipes, http,
whatever.  Since it sounds like you can't introduce any additional
software packages, you might want to consider using RMI (see the
java.rmi package).  At least then, you're coding to an API instead of
having to invent message formats and protocols.


On Tue, 2014-10-28 at 10:16 -0400, Jason Ricles wrote:

Yes we are trying to portable, well the socket is the last resort. We are
trying to avoid it until now but will go that way if we have to if there

is

no other way. Mostly due to the data coming in and out writing our own
socket will be complex but doable. As far as messaging broker, they are

not

approved for use on our system so thus can not be used.

On Tue, Oct 28, 2014 at 10:13 AM, Tim Watts t...@cliftonfarm.org wrote:


On Linux/Unix you could use a FIFO (aka named pipe) and have each side
connect to it with a stream.  But that's non-portable and probably not
too elegant/robust.  What's the problem with using a socket?  Or better
yet, a message broker like ActiveMQ like someone else has already
suggested?


On Tue, 2014-10-28 at 09:46 -0400, Jason Ricles wrote:

Communicate means something happens that the daemon is monitoring, so

thus

the daemon sends a message to the websocket server running on the

webapp,

so that message can get relayed to the webpage from the server and

the

daemon will also need to get messages from the webapp. It will then

be

two

way and just regular messages.

On Tue, Oct 28, 2014 at 9:42 AM, chris derham ch...@derham.me.uk

wrote:

On 28 October 2014 11:06, Jason Ricles jgr...@alum.lehigh.edu

wrote:

Ok so here is the problem I have been spinning my wheels on for

day

let

me

just lay it out.

I have a daemon written in java running lets call it foo for

simpleness

on

a linux machine that has the tomcat server running. On the tomcat

server

is

a WAR file for a webapp called bar. In that webapp is a webpage

with

JavaScript websocket communication that connects to a websocket

server

that

is also a part of the WAR file. So I have a webpage and a

websocket

server

communicating with each other.

I want the foo daemon and the websocket server on bar (web

application)

to

be able to communicate with each other. Is there any way outside

of

sockets

to have foo and the websocket server on bar do this?

Define communicate - what kind? One way, two way, what kind of

data,

frequency, size, type?

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





-
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: HTTPS / URLs with no port number / Tomcat only

2014-10-28 Thread Terence M. Bandoian

On 10/28/2014 8:55 AM, Léa Massiot wrote:

Christopher Schultz-2 wrote

A bit of warning: when modifying iptables, you need to be very careful
that you don't wipe-out any rules that allow you to gain remote access
to the server. For instance, if you have a default rule to DROP all
packets and an exception that allows port 22 (ssh) traffic, then
flushing all the rules in a table can make it impossible for you to
revert the change without remote-rebooting (or, worse yet, paying
someone to walk into the cage and push the reset button).

Yes right, fortunately I wasn't working on a remote machine.

On Debian Wheezy, the following set of commands actually disables the
firewall:
---
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
---

Best regards.



Hi, Léa-

Ideally, I think you'd want to permanently modify the iptables rules to 
enable traffic over the desired port.  Doing so would keep the existing 
safety measures in place and all of the rules would survive a reboot.  
However, if you just want to temporarily disable iptables, I believe


service iptables stop

would do so.  Permanently disabling iptables would require a little more 
work as, in my experience, it is typically configured to start when the 
system is booted.


-Terence Bandoian






--
View this message in context: 
http://tomcat.10.x6.nabble.com/HTTPS-URLs-with-no-port-number-Tomcat-only-tp5024482p5024571.html
Sent from the Tomcat - User mailing list archive at Nabble.com.




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



Built-in Tomcat Support for Windows Authentication

2014-10-22 Thread Terence M. Bandoian

On 10/22/2014 4:40 AM, Philippe Wijdh wrote:

Hello,

We have spent a long time now, trying to set up Apache Tomcat with Windows 
Authentication.
We followed the instructions as per 
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html but we cannot 
make it work properly, the logon dialog keeps appearing and trying to log on 
fails.
Additional to that we tried suggestions, like adding the registry key 
AllowTgtSessionKey and setting it to 0x01
Seems like we are close but we are missing something (see tomcat output below)
Does anyone have a more complete documentation or have any suggestions on how 
to make this work.


Kind regards,

Philippe Wijdh



Extra information on the setup:

Windows 2008 r2 sp1
Apache Tomcat 7.0.54
jdk1.7.0_60

Tomcat is running as a service using account  HTTP/v3tcat4ad.assai.nl:8080 
(have created spn with and without the port number, does not make a difference)

Test is done with user testu...@assai.nlmailto:testu...@assai.nl in IE11 on 
different machines, with http://v3tcat4ad.assai.nl explicitly added to the Intranet 
sites.



Hi, Philippe-

I have not used the built-in Tomcat Windows authentication but have had 
success using Waffle in a similar configuration.  You might try that if 
all else fails.


-Terence Bandoian






Tomcat Output:


KeyTabInputStream, readName(): ASSAI.NL
KeyTabInputStream, readName(): HTTP
KeyTabInputStream, readName(): v3tcat4ad.assai.nl:8080
KeyTab: load() entry length: 72; type: 23

Java config name: C:\MyPrograms\Tomcat7\conf\krb5.conf
Loaded from Java config
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.

KdcAccessibility: reset

Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.
default etypes for default_tkt_enctypes: 23 18 17.

KrbAsReq creating message
KrbKdcReq send: kdc=v3dom1.assai.nl UDP:88, timeout=3, number of retries 
=3, #bytes=152
KDCCommunication: kdc=v3dom1.assai.nl UDP:88, timeout=3,Attempt =1, 
#bytes=152
KrbKdcReq send: #bytes read=173
Pre-Authentication Data:

 PA-DATA type = 11
 PA-ETYPE-INFO etype = 23, salt =


Pre-Authentication Data:

 PA-DATA type = 19
 PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null


Pre-Authentication Data:

 PA-DATA type = 2
 PA-ENC-TIMESTAMP

Pre-Authentication Data:

 PA-DATA type = 16


Pre-Authentication Data:

 PA-DATA type = 15


KdcAccessibility: remove v3dom1.assai.nl:88
KDCRep: init() encoding tag is 126 req type is 11
KRBError:

 sTime is Wed Oct 22 09:53:56 CEST 2014 1413964436000
 suSec is 403143
 error code is 25
 error Message is Additional pre-authentication required
 realm is ASSAI.NL
 sname is krbtgt/ASSAI.NL
 eData provided.
 msgType is 30

Pre-Authentication Data:

 PA-DATA type = 11
 PA-ETYPE-INFO etype = 23, salt =


Pre-Authentication Data:

 PA-DATA type = 19
 PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null


Pre-Authentication Data:

 PA-DATA type = 2
 PA-ENC-TIMESTAMP

Pre-Authentication Data:

 PA-DATA type = 16


Pre-Authentication Data:

 PA-DATA type = 15

KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 23 18 17.
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.
default etypes for default_tkt_enctypes: 23 18 17.

EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
KrbAsReq creating message
KrbKdcReq send: kdc=v3dom1.assai.nl UDP:88, timeout=3, number of retries 
=3, #bytes=235
KDCCommunication: kdc=v3dom1.assai.nl UDP:88, timeout=3,Attempt =1, 
#bytes=235
KrbKdcReq send: #bytes read=1446
KdcAccessibility: remove v3dom1.assai.nl:88

Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.

EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
KrbAsRep cons in KrbAsReq.getReply HTTP/v3tcat4ad.assai.nl:8080

Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.
Search Subject for SPNEGO ACCEPT cred (DEF, 
sun.security.jgss.spnego.SpNegoCredElement)
Search Subject for Kerberos V5 ACCEPT cred (DEF, 
sun.security.jgss.krb5.Krb5AcceptCredential)
Found KeyTab
Found KerberosKey for HTTP/v3tcat4ad.assai.nl:8...@assai.nl
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 18 17.
Added key: 23version: 0
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23 

java.lang.IllegalArgumentException at java.nio.Buffer.limit

2014-08-07 Thread Terence M. Bandoian

On 8/7/2014 10:04 AM, John Smith wrote:

TC 7.0.54 / RHEL 6 / JDK 1.7.0_60

I'm getting a pretty consistent error in my logs that started showing up
recently. I use logback and have a servlet catch all 500 errors and log
them. The error seems to be associated with one servlet that writes XML
output.

Two changes I made recently were implement SSL for one subdirectory on the
webapp, and removing redirects in IPTables to the HWLB. I can't really
think of any other code level changes that might have caused the change in
behavior. Please let me know if you need more information. Any thoughts?

The writeXML method is:

protected void writeXML(HttpServletResponse res, String xml) throws
IOException {
 res.setContentType(text/xml);
 PrintWriter out = res.getWriter();
 out.write(xml);
 out.close();
}


The stacktrace almost always looks like this:
_
14:18:59.617 [http-nio-8080-exec-45] ERROR c.m.SiteExceptionHandlerServlet
- Stacktrace was: java.lang.IllegalArgumentException
at java.nio.Buffer.limit(Buffer.java:267)
at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:85)
at
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:481)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:464)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:384)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:554)
at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:174)
at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:184)
at com.mysite.AbstractServlet.writeXML(AbstractServlet.java:182)
at com.mysite.level.GetLevelServlet.getAllAsXML(GetLevelServlet.java:82)
at com.mysite.level.GetLevelServlet.manageActions(GetLevelServlet.java:33)
at com.mysite.AbstractServlet.doPost(AbstractServlet.java:52)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
...
__

Although there are variations like:

Stacktrace was: java.lang.IllegalArgumentException
at java.nio.Buffer.position(Buffer.java:236)
at sun.nio.cs.ISO_8859_1$Encoder.encodeArrayLoop(ISO_8859_1.java:179)
at sun.nio.cs.ISO_8859_1$Encoder.encodeLoop(ISO_8859_1.java:212)
at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561)
at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:108)
at
org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:481)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:464)
at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:384)
at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:554)
at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:174)
at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:184)
at com.mysite.AbstractServlet.writeXML(AbstractServlet.java:182)

___




What's on line 182 of AbstractServlet.java?

-Terence Bandoian


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



Security Manager Exception

2014-07-23 Thread Terence M. Bandoian

On 7/22/2014 11:04 AM, George Sexton wrote:
I'm using Tomcat 7.0.54 with the security manager. I'm getting an 
exception I don't understand:


2014-07-22 09:27:03,934 [http-bio-80-exec-64] ERROR 
org.apache.catalina.core.ContainerBase.[Catalina].[somehostname.mhsoftware.com].[/].[jsp]- 
Servlet.service() for servlet [jsp] in context with path [] threw 
exception [java.security.AccessControlException: access denied 
(java.lang.RuntimePermission getClassLoader)] with root cause
java.security.AccessControlException: access denied 
(java.lang.RuntimePermission getClassLoader)
at java.security.AccessControlContext.checkPermission(Unknown 
Source)

at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.ClassLoader.checkClassLoaderPermission(Unknown 
Source)

at java.lang.ClassLoader.getParent(Unknown Source)
at 
org.apache.juli.ClassLoaderLogManager.findProperty(ClassLoaderLogManager.java:295)
at 
org.apache.juli.ClassLoaderLogManager.getProperty(ClassLoaderLogManager.java:266)
at 
org.apache.juli.ClassLoaderLogManager.addLogger(ClassLoaderLogManager.java:144)

at java.util.logging.LogManager.demandLogger(Unknown Source)
at java.util.logging.Logger.demandLogger(Unknown Source)
at java.util.logging.Logger.getLogger(Unknown Source)
at com.sun.mail.util.MailLogger.init(MailLogger.java:115)
at javax.mail.Session.initLogger(Session.java:226)
at javax.mail.Session.init(Session.java:210)
at javax.mail.Session.getInstance(Session.java:247)
at com.MHSoftware.net.mail.MHMail.sendSMTP(MHMail.java:470)


Line 144 of ClassLoaderLogManager is the addLogger method trying to 
read the .level property for the logger being created.


The catalina.policy is pretty much the stock one. I'm confused because 
the catalina.policy has:


grant codeBase file:${catalina.home}/bin/tomcat-juli.jar {
permission java.lang.RuntimePermission getClassLoader;

The page in question that's erroring out is a JSP that's calling a 
per-context jar. The hierarchy looks something like:


JSP -
context/WEB-INF/lib/jar Class File -
$CATALINA_BASE/lib/ MH Software.jar -
$CATALINA_BASE javax.mail.jar -
$CATALINA_HOME/bin/tomcat-juli.jar

$CATALINA_BASE/lib, has the grant for java.security.AllPermission;

I don't know if this makes a difference, but I'm using log4j, and 
following the instructions here:


http://tomcat.apache.org/tomcat-7.0-doc/logging.html#Using_Log4j

I've made $CATALINA_BASE/conf/logging.properties an empty file.

Finally, it SEEMS to only be happening in JSP files. calls directly 
from classes in the context jar file don't seem to be failing.


If anyone could point me in the right direction, I would really 
appreciate it.






Have you granted permissions to the classes in WEB-INF?

-Terence Bandoian


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



Re: Help understanding Session System Properties

2014-07-22 Thread Terence M. Bandoian

On 7/22/2014 9:36 AM, Felipe Jaekel wrote:

I have a simple authentication logic in my applications, where I store the
current user in the session and check with a filter if the current user
value is not null.

Eventually I see some null pointer exceptions in my Tomcat 7.0.47 that
happened in JSF managed beans because the current user value was null.

The problem is that the stackTrace shows that login filter was executed
correctly, so I guess the session timed out right after the getAttribute()
call in the filter, which would explain why there still was value in the
filter but not in the managed bean.

After some research I found this:
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions

Would org.apache.catalina.session.StandardSession.ACTIVITY_CHECK solve this
problem?

What about org.apache.catalina.core.StandardHostValve.ACCESS_SESSION and
org.apache.catalina.session.StandardSession.LAST_ACCESS_AT_START?

Thanks



Hi, Felipe-

What's your session timeout setting?  IIRC, the session timer is reset 
every time a new request associated with that session is received.  Is 
the session object accessed outside the scope of processing a request 
(i.e. from a thread you've created)?


-Terence Bandoian


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



Re: Problem with Transfer-Encoding

2014-07-09 Thread Terence M. Bandoian

On 7/8/2014 2:52 AM, Konstantin Kolinko wrote:

2014-07-07 21:07 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 7/5/2014 6:36 PM, André Warnier wrote:

I agree with André about the difficulties of debugging character encodings.
A couple of things you might check are the character encodings of the page
and the form.  The character encoding of the page may be set with the
Content-type meta tag:

meta http-equiv=ontent-type content=text/html;charset=UTF-8/


Setting explicit value for content attribute like that is risky. The
value must match the Content-Type HTTP header produced by web server.
If they do not match, some browsers ignore both and start guessing the
encoding.

I usually write it as

%@ page contentType=ext/html; charset=UTF-8 %
...
META http-equiv=ontent-type content=%=response.getContentType() %

Best regards,
Konstantin Kolinko



Hi, Konstantin-

With JSP pages, I use contentType attribute of the page directive as 
well but didn't think to include it in my reply.  Thanks for pointing it 
out.


-Terence Bandoian


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



Re: Host appBase vs Context docBase

2014-07-07 Thread Terence M. Bandoian

On 7/5/2014 1:38 PM, Igal @ getRailo.org wrote:

What version of Tomcat are you using?

I've been using Tomcat 6 and 7 for a while, and now running Tomcat 8.

it is recommended that Context elements not be placed directly in 
server.xml
I know, but it is much easier for me to edit a single file, server.xml 
then deploy all the other files.  I'm looking to keep the deployment 
process as simple as possible.


you shouldn't need the empty directory. I've used an absolute path 
for the Host appBase attribute with relative paths for Context 
docBase attributes in Tomcat 6 and 7 without any problems.
when I try that then webapps is used by default.  if a request is 
made for a file that exists in webapps, e.g. index.jsp and does not 
exist in my application's folder, then it is served from webapps and I 
don't want that.


are you sure you want / for the Context path attribute in the 
first example above?
it was my understanding that  and / are the same here.  / reads 
more clearly to me as the root directory so I prefer to use that.


*after reading your email and testing it, however, I noticed that if I 
omit the Host/appBase and use an empty-string for the 
Context/docBase/path it works as intended, so maybe that's what I was 
doing wrong?  is that the best practice?*


Host name=Site1 unpackWARs=false autoDeploy=false
  Context path= docBase=D:/www/site1 /
  Context path=/virtualdir docBase=D:/www/shared/virtualdir /
/Host

?

thank you both for your responses,


Igal


On 7/5/2014 9:48 AM, Terence M. Bandoian wrote:

On 7/4/2014 9:04 PM, Igal @ getRailo.org wrote:

I'm a little confused about the Host appBase attribute.

Let's say that my website resides in D:\www\site1

I don't like using {Tomcat}/webapps so I don't want to have it as a 
base directory for websites.  What I've been doing so far is create 
an empty folder alongside webapps, named empty, and use it as 
appBase, e.g.


Host name=Site1 appBase=empty unpackWARs=false 
autoDeploy=false

  !-- this works but what's the deal with appBase? !--
  Context path=/ docBase=D:/www/site1 /
/Host

But it feels like I'm doing something wrong.  I expect this to work, 
but it doesn't:


Host name=Site1 appBase=D:/www/site1 unpackWARs=false 
autoDeploy=false

  !-- this doesn't work !--
/Host

Can anyone explain why the snippet above doesn't work, and if that 
is the way it should be, then what is the purpose of Host/appBase?


TIA



Hi, Igal-

What version of Tomcat are you using?  Also, it is recommended that 
Context elements not be placed directly in server.xml.  See:


http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context 



That said, you shouldn't need the empty directory.  I've used an 
absolute path for the Host appBase attribute with relative paths 
for Context docBase attributes in Tomcat 6 and 7 without any 
problems.  I haven't tried it with absolute paths for both appBase 
and docBase.


Lastly, are you sure you want / for the Context path attribute in 
the first example above?  The Context path for the default web 
application of a Host should be an empty string ().  See:


http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes 



-Terence Bandoian


Hi, Igal-

Glad you were able to get it working.  Please note the warning in the 
Tomcat docs about using the Context path attribute that reads:


Even when statically defining a Context in server.xml, this attribute 
must not be set unless either the docBase is not located under the 
Host's appBase or both deployOnStartup and autoDeploy are false. If this 
rule is not followed, double deployment is likely to result.


This is included in:

http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Common_Attributes

For information about about how context paths relate to WAR file names 
and application directory names, see:


http://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Naming

In particular, please note that If the context path is the empty string 
them the base name will be ROOT (always in upper case)


The recommended practice is to create separate context XML files and 
package them in the application WAR files.  However, for simple 
installations, I've had success with something like:


  Host name=Host
  appBase=c:/webapps
  autoDeploy=false
  deployOnStartup=true
  unpackWARs=true

Context path= docBase=ROOT /

  /Host

The [Tomcat]/webapps directory may then be deleted (if you don't need 
the packaged apps or doc) and ROOT.war placed directly in c:/webapps.


-Terence Bandoian


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



Re: Problem with Transfer-Encoding

2014-07-07 Thread Terence M. Bandoian

On 7/5/2014 6:36 PM, André Warnier wrote:

Sushil Prusty wrote:

Dear User

Thanks for you input.


You're welcome.
First, a foreword : I will try my best to help you, but doing this is 
very difficult, and doing it via email is even more difficult.
I was not kidding when I wrote earlier that even looking at the data 
may make it change.
Of course, that is not really true, but the fact of cutting and 
pasting this data, from your saved HTTPFox trace into an email that 
you send to the Tomcat list, and then the Tomcat list server 
forwarding this to other people in a new email, may again decode and 
re-encode this data several times, and confuse the situation totally.
So we need to be very, very systematic, and make sure that what we see 
is really what we get, ok ?


What you should really do, is to save the original HttpFox data to a 
file, then save that file, then zip that file, then post it somewhere 
where we can get this zip-file.
So that we can download it, unzip it, and then be sure that we are 
really seeing the same data as you do.


In the meantime, a question :


I just debugged using HttpFox here is below you find header

(Request-Line)POST /test/testUserEditAction.do?dojoIframeSend=true


The above request line is triggered by something.
By what ?
Is that a link or button on a HTML page which is currently loaded in 
your browser ?


If yes, then before you actually click this link, can you in your 
browser use the View..Character set function, and tells us what the 
browser thinks about the current page loaded in the browser, before 
you even send this request to the server ?


The reason why I am asking, is that this is the character set which 
the browser will most probably use to encode the text data that it 
sends to the server (when you click the link).



Then see the note below, in the text.



I agree with André about the difficulties of debugging character 
encodings.  A couple of things you might check are the character 
encodings of the page and the form.  The character encoding of the page 
may be set with the Content-type meta tag:


meta http-equiv=Content-type content=text/html;charset=UTF-8/

For the form, I believe the character encoding defaults to the character 
encoding of the page but may be explicitly set with the accept-charset 
attribute:


form method=post action=action.do accept-charset=utf-8/form

Hope that helps.

-Terence Bandoian





HTTP/1.1
Host**
User-AgentMozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:30.0)
Gecko/20100101 Firefox/30.0
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Languageen-US,en;q=0.5
Accept-Encodinggzip, deflate
Refererhttps://s
Action.do?action=loginflashVersion=9.0.47.0hasCorrectFlashVersion=falseproduct=xyz 


CookieJSESSIONID=**; doNotShowStartupOnLoad=true
Connectionkeep-alive
Content-Typemultipart/form-data;
boundary=---***
Content-Length4039


In Post body


-1550434539176507601876254213
Content-Disposition: form-data; name=disclaimerText

Zażółć gęślÄ jaźń! ta funkcjonalność nie jest wspierana


The line above may or may not have been further corrupted (compared to 
the original that you see), by the simple fact of copying this text 
into your email.
But assuming for a moment that it was not, and that it really is what 
it looks like above, there is some kind of a problem :


(You'll have to follow carefully here)
If I take the original text line which you posted in your first message :

Zażółć gęślą jaźń! ta funkcjonalność nie jest wspierana*

and I imagine that internally, this is encoded as UTF-8;
Then if I look at that same series of UTF-8 characters, but now 
examine the *bytes* that compose these characters and view them in 
ASCII, I should see this :


Zażółć gęślą jaźń! ta funkcjonalność nie jest wspierana*

But if you compare this carefully, with the string as it appears in 
your HttpFox trace, you will see that it does not match exactly. For 
example, look at the last 2 letters of the word funkcjonalność, in 
both versions.


So there appears to be some discrepancy between the character set 
which your browser is really using (to send data to the server), and 
the UTF-8 that your server seems to expect.


Furthermore (and put this on account of my suspicious nature if you 
want) :
The second part of that message, in Polish, means : This 
functionality is not supported.
Which triggers the question : what kind of HTML page would be sending 
this phrase, as part of the data, in a POST to a server ? Can you give 
us some context as to what you are trying to do here ?





-1550434539176507601876254213

I believe psot data got changed before   reaching   to server .

  Do you have any ideas what's wrong here, where the error might be ?




On Sat, Jul 5, 2014 at 9:08 PM, André Warnier a...@ice-sa.com 

Re: Host appBase vs Context docBase

2014-07-05 Thread Terence M. Bandoian

On 7/4/2014 9:04 PM, Igal @ getRailo.org wrote:

I'm a little confused about the Host appBase attribute.

Let's say that my website resides in D:\www\site1

I don't like using {Tomcat}/webapps so I don't want to have it as a 
base directory for websites.  What I've been doing so far is create an 
empty folder alongside webapps, named empty, and use it as 
appBase, e.g.


Host name=Site1 appBase=empty unpackWARs=false autoDeploy=false
  !-- this works but what's the deal with appBase? !--
  Context path=/ docBase=D:/www/site1 /
/Host

But it feels like I'm doing something wrong.  I expect this to work, 
but it doesn't:


Host name=Site1 appBase=D:/www/site1 unpackWARs=false 
autoDeploy=false

  !-- this doesn't work !--
/Host

Can anyone explain why the snippet above doesn't work, and if that is 
the way it should be, then what is the purpose of Host/appBase?


TIA



Hi, Igal-

What version of Tomcat are you using?  Also, it is recommended that 
Context elements not be placed directly in server.xml.  See:


http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context

That said, you shouldn't need the empty directory.  I've used an 
absolute path for the Host appBase attribute with relative paths for 
Context docBase attributes in Tomcat 6 and 7 without any problems.  I 
haven't tried it with absolute paths for both appBase and docBase.


Lastly, are you sure you want / for the Context path attribute in 
the first example above?  The Context path for the default web 
application of a Host should be an empty string ().  See:


http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Common_Attributes

-Terence Bandoian

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



Re: Browsers suddenly start timing out when accessing port 80 of secure site

2014-06-26 Thread Terence M. Bandoian

On 6/24/2014 12:25 PM, Bruce Lombardi wrote:

Thanks for the response Konstantinos. I'll look into the HSTS header. The 
behavior you describe may be what is happening.

Bruce

Sent from my iPad


On Jun 24, 2014, at 8:51 AM, Konstantin Preißer kpreis...@apache.org wrote:

Hi,


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, June 24, 2014 2:42 PM
To: Tomcat Users List
Subject: Re: Browsers suddenly start timing out when accessing port 80 of
secure site

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bruce,


On 6/23/14, 2:30 PM, Bruce Lombardi wrote:
Moving the SSL port from 8443 to 443 has solved the problem. It
appears that when the url www.something.net is entered, Firefox
remembers that this is an SSL site and automatically add the s
to get https. In fact after the timeout the url line in the
browser shows https:www.something.net. Obviously, this is
defaulting to the standard SSL port (443), which does not work if
8443 is used. Moving the port to 443 solved the problem.

If you read about setting up Tomcat, the default SSL port is 8443.
Maybe this is done for testing, but it never seems to be explained
that there might be problems with 8443.

I have never experienced the behavior you describe. Certain clients do
cache responses from servers, so it's possible that you had a bad setup
at some point that redirected :80 - :443 and then Firefox wouldn't
forget that response and change to :8443.

It might also be possible that the website used HSTS which forces compliant browsers (hopefully IE 
too in near future) to only view a site in HTTPS. I haven't tested how Firefox handles this, but I 
can imagine that when the website on :8443 sets an HSTS header and the user enters 
www.example.com, that Firefox automatically switches this to 
https://www.example.com/; which is Port 443.


Regards,
Konstantin Preißer



There is a nice description on Mozilla:

https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security

Thanks for pointing this out.

-Terence Bandoian

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



Re: Webapps directory query

2014-06-20 Thread Terence M. Bandoian

On 6/20/2014 12:53 AM, vicky wrote:

Thanks Mark, but it doesn't have the details of scenario when we'll carry out a 
redeployment along with a restart/

How the exploded directories will then be updated , is it only the files are 
going to be updated within it ?

Please give some directions.

  Vicky

  



On Friday, 20 June 2014 11:00 AM, Mark Eggers its_toas...@yahoo.com.INVALID 
wrote:
  



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 6/19/2014 10:12 PM, vicky wrote:

Hi Guys,

Ideally when a redeployment happens in a tomcat , is it standard
that the exploded war directory will again be

updated with the latest timestamps or is it the case that only
files will be updated within that  directory.

Please share if there is any online documentation available for
this behavior


Kindly suggest


Thanks Vicky


Please read the following links, and search for the word 'redeploy'.

http://tomcat.apache.org/tomcat-6.0-doc/deployer-howto.html
http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html
http://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html

. . . just my two cents
/mde/



Hi, Vicky-

I'd suggest testing.

-Terence Bandoian

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



Re: Tomcat is down or refused connection

2014-05-23 Thread Terence M. Bandoian
On 5/23/2014 1:22 AM, Ballarpure, Akshay (EXT-Tata Consultancy Ser - 
IN/Hyderabad) wrote:



Hello,
Soap request is failing with below message in our application.

2014/05/20 06:48:43 [ERROR]   (browse_csl)   failed to reach 
startSearch service, soapRC 502
2014/05/20 06:48:43 [ERROR]   (soap)Error 502 fault: 
SOAP-ENV:Server [no subcode]

I am seeing below messages in Apache's Mod JK log file.

[Tue May 20 06:48:43 2014] [57070:140373099702016] [error] 
ajp_get_reply::jk_ajp_common.c (2126): (worker1) Tomcat is down or refused 
connection. No response has been sent to the client (yet)
[Tue May 20 06:48:43 2014] [56884:140373020112640] [error] 
ajp_service::jk_ajp_common.c (2643): (worker1) connecting to tomcat failed.

Could you please check and let me know the reason for the above ?

Thanks,
Akshay



Sounds like Tomcat is down.

-Terence Bandoian

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



Re: tomcat6 thread locked

2014-05-21 Thread Terence M. Bandoian

On 5/20/2014 8:28 PM, devoss ind wrote:

Hi Christopher,

Can you suggest stable tomcat and jvm versions.

Regards,
Devoss.
On 20 May 2014 21:32, Christopher Schultz ch...@christopherschultz.net
wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Devoss,

On 5/19/14, 2:43 AM, devoss ind wrote:

Exact Tomcat version is 6.0.16

This version of Tomcat is profoundly old: more than 6 years. There are
documented and well-understood vulnerabilities in that (and later)
versions of Tomcat 6.0.x that will allow unauthenticated remote
attackers to subvert certain authentication mechanisms, mount XSS and
CSRF attacks, and trivially launch non-distributed denial-of-service
attacks against your server(s).

Continued use of it is reckless to be polite. You absolutely
positively need to upgrade immediately.


OS Version is RHEL Server release 5.3(Tikanga) Java version is
1.6.0_10

All that stuff is fairly old as well.

Upgrade Tomcat and your JVM and re-test, please.

- -chris


On Fri, May 16, 2014 at 9:15 PM, Christopher Schultz 
ch...@christopherschultz.net wrote:

devoss,

Exact Tomcat version? OS and version? Java version?

On 5/15/14, 12:00 PM, devoss ind wrote:

On 7 May 2014 17:37, devoss ind devoss@gmail.com
wrote:

Hi,

Am using tomcat 6, java6 in production environment to run
our web

application. We found that recently, cpu in top is showing
100% nearly. Then we dig into each thread cpu usage by -H
option in top. We found only one thread is taking 100%usage
and identified the thread using thread dump. The thread dump
for that particular thread which is using 100% usage is as
follows...

http-8080-exec-3687 daemon prio=10 tid=0x7336f400
nid=0x41a1 runnable

[0x619ad000..0x619ade30]

java.lang.Thread.State: RUNNABLE at

org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:616)



- - locked 0x967b22f0 (a

org.apache.coyote.http11.InternalNioOutputBuffer)

at

org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:608)



at
org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:1024)



at org.apache.coyote.Response.action(Response.java:183)

at
org.apache.coyote.Response.sendHeaders(Response.java:379)
at

org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:305)
at
org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
at

org.apache.catalina.connector.Response.flushBuffer(Response.java:548)

at
org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:345)



at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:144)



at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)



at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)



at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)



at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:879)



at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:719)



at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2080)



at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)



at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)



at java.lang.Thread.run(Thread.java:619)

We can see that above thread is locked due to some problem
in NIO.

We have verified in tomcat manager also for such thread. We
found that a

particular thread is taking 14140517ms time and the request
in that line is of POST request which is not related to our
application.

That particular thread is not releasing till we restart
tomcat.

This is happening frequently.

Please help me to find out the root cause of this problem.
How to avoid

restarts.

Our server.xml connector configuration is as follows...

Connector port=${http.port}

protocol=org.apache.coyote.http11.Http11NioProtocol

connectionTimeout=5000 acceptCount=1500
maxThreads=1 redirectPort=8443 /

Please help in this thread locking problem.



http://tomcat.apache.org/whichversion.html

Also, the convention on the Tomcat users list is to respond below the 
previous message.  Please see 6. in:


http://tomcat.apache.org/lists.html#tomcat-users

-Terence Bandoian

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



RE: Tomcat dependency on application server

2014-05-17 Thread Terence M. Bandoian

On 5/17/2014 4:35 AM, Randhir Singh wrote:

I have 1 observation. In our developmental environment, I killed the Tomcat
process and started the Tomcat it worked. But in the production environment,
starting Tomcat was not enough and I had to restart JBoss  Tomcat in
sequence for Tomcat to be up. Could it mean that JVM is crashing or
something because of OOME in Tomcat.

I could try to increase the heap  Permgen memory in Tomcat, would that
help?

Requesting a reply.

Regards

-Original Message-
From: Randhir Singh [mailto:randhir.si...@sterlite.com]
Sent: Saturday, May 17, 2014 11:00 AM
To: 'Tomcat Users List'
Subject: RE: Tomcat dependency on application server

Thanks Chris for your answer. There were separate PID's on Linux for JBoss 
Tomcat and I killed the Tomcat process. Would killing a Tomcat process also
kill the JVM process? I had another related question of how to know the
number of JVM's running, I mean the count of the number of JVM's.

I hope, my query has been put across correctly.

Requesting a reply.

Regards

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Saturday, May 17, 2014 1:59 AM
To: Tomcat Users List
Subject: Re: Tomcat dependency on application server

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Randhir,

On 5/15/14, 3:17 AM, Randhir Singh wrote:

Hi,

We have JBoss as the application server  Tomcat as the web server in
our production  developmental setup which is on Red Hat Linux 5.X. We
have tomcat 6.X. My query is that if I need to restart tomcat, do I
need to restart JBoss  Tomcat both or just restarting Tomcat would be
enough. I am asking this query because I had killed the tomcat process
using kill -9 and while restarting tomcat it was not starting but when
I killed JBoss  tomcat and then restarted, Tomcat was up.

I hope my query is clear whether Tomcat is dependent on JBoss.

I'm fairly sure that there is only a single JVM for JBoss/Tomcat. If you
killed one, you've killed the other.

- -chris



From what I've read, JBoss is based on a forked version of Tomcat and 
shouldn't need a separate instance of Tomcat to function.  Are you using 
them together to serve separate content?  If so, why?


-Terence Bandoian


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



Re: where find documentation

2014-05-16 Thread Terence M. Bandoian

On 5/15/2014 8:05 AM, Francesco Viscomi wrote:

Hi all,
i'm try to find a documentation that describe every tag inside the web.xml
file, but i wasn't able to find anything about that on
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html


someone can help me?
thanks in advance;
Francesco
Italy



Which version of Tomcat are you using?  Your link above is for 5.5. Go to:

http://tomcat.apache.org/

for links to documentation for other versions of Tomcat.

web.xml is documented in the servlet specifications.  Links to servlet 
specifications may be found on the Tomcat wiki:


http://wiki.apache.org/tomcat/Specifications

Hope that helps.

-Terence Bandoian

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



Re: Session fixation Tomcat 7

2014-05-16 Thread Terence M. Bandoian

On 5/8/2014 8:56 PM, Akash Jain wrote:

Hi,

I am trying to resolve session fixation issue with tomcat 7.0.52

We have a Spring MVC application running on it, and the Auth method is
provided by another application which writes cookie, and we use the cookie
value to check whether the user is valid or not.

My application URL patterns are
/ - Home page
/login - Redirect to another application to ask user to authenticate
/myaccess/user*** -- All authenticated URL's

Context path=
  docBase=myapplication
  sessionCookieName=mycookiename
  sessionCookieDomain=application.mydomain.com
  sessionCookiePath=/

As I cannot use org.apache.catalina.authenticator.FormAuthenticator here.

How can i prevent the session fixation ?

Thanks.



Do all communications use SSL or TLS?

-Terence Bandoian


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



Re: No activity on tomcat.users since Tues?

2014-05-12 Thread Terence M. Bandoian

On 5/11/2014 7:56 AM, Konstantin Kolinko wrote:

2014-05-10 22:54 GMT+04:00 Tim Watts t...@cliftonfarm.org:

Markmail seems to confirm this but kind of remarkable, huh?  I think the
user community should get a promotion in recognition of our quantum leap
in tomcat problem-solving skills!  (Or perhaps everyone's just busy
reading the manual?)


I thought so for a day or two, but it is actually mail server outage at ASF.

There is announcement at http://tomcat.apache.org/
and original one at https://blogs.apache.org/infra/

They say that the server is fixed. I see that fresh e-mails (such as
yours) are successfully coming through.

The old e-mails are in a delivery queue which is being processed now.
Thus far I have received ~10 commit e-mails out of ~50 for the outage
days. They come in some random order. As there were hard drive
failures and as the outage was long, I think some e-mails might be
lost.

Best regards,
Konstantin Kolinko




Silly me.  I thought it was something I said.

-Terence Bandoian

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



RE: Setup Issue tomcat 6 SLES 11 SSL

2014-05-01 Thread Terence M. Bandoian

On 4/30/2014 3:35 PM, Vincent T. DiScipio wrote:

Terence,

I poked around in the configuration file and knew it was something I did to 
screw it up.  I just scrapped the install and started from fresh.

Thanks for the reply

Vince DiScipio
Director of Digital Infrastructure
The College of Wooster
P - 330-263-2612
F - 330-263-2666

-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Wednesday, April 30, 2014 3:01 PM
To: Tomcat Users List
Subject: Re: Setup Issue tomcat 6 SLES 11 SSL

On 4/30/2014 9:02 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vincent,

On 4/29/14, 4:24 PM, Vincent T. DiScipio wrote:

I have setup tomcat 6 on SLES 11 and secured the instance with an
external certificate if authority.  The following is occurring from
the same machine using both IE and Firefox:

http://servername.wooster.edu:8080works for both IE11 and
Firefox 29 and displays the index.html

https://servername.wooster.edu:8443  works for Firefox 29 and
displays the index.html

https://servername.wooster.edu:8443  does not work for IE11v displays
This page can't be displayed

I have changed the logging level to finest and do not see any errors
in the catalina.out.

Thoughts?  I have the same setup on another server and I believe the
files and permission levels are set the same.

What does your SSL configuration look like?

You could also use either sslscan from the CLI or go to
https://www.ssllabs.com/ssltest/ and use their online tool to examine
the site from the outside.

Perhaps you have a combination of protocols and ciphers that MSIE
can't handle.

- -chris


If the option is available, you might also try disabling the IE friendly 
error messages.  I'm not sure about IE 11, but it seems like previous versions displayed 
an error message with a reddish background if they were unable to authenticate a server 
with a given SSL certificate.  Was a certificate authority bundle supplied with the SSL 
certificate?  If so, is it installed and configured?  Were the SSL certificates on the 
both servers issued by the same company?

-Terence Bandoian



Smart.  Thanks for the update.

-Terence Bandoian


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



Re: CORS issue with Tomcat and Android Webview

2014-04-30 Thread Terence M. Bandoian

On 4/29/2014 3:48 AM, Jose María Zaragoza wrote:

2014-04-29 0:38 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/28/2014 5:32 PM, Terence M. Bandoian wrote:

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com:

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
tere...@tmbsw.comwrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So
shouldn't
CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards


Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at all.
Can you point me to where you've found that?

-Terence Bandoian



I meant to say I don't see where the W3C spec requires preflight requests to
be sent.

According to

http://www.w3.org/TR/cors/#simple-cross-origin-request
Cross-Origin Request with Preflight
[
Go to the next step if the following conditions are true. *Otherwise,
make a preflight request.*

- For request method there either is a method cache match or it is a
simple method and the force preflight flag is unset.
- For every header of author request headers there either is a header
cache match for the field name or it is a simple header.
/]

So, I understand that if I make a POST request within application/xml
content-type header, it's a simple method but Content-type:
application/xml is not a simple header, according to
http://www.w3.org/TR/cors/#simple-method
I understand that client must to make a preflight request

Maybe I'm wrong


Regards



Hi, Jose,

I see that now but the logic behind it is a little confusing.  In 
particular, the following sentence at the beginning of the section you 
referenced is not clear to me:


To protect resources against cross-origin requests that could not 
originate from certain user agents before this specification existed a 
preflight request is made to ensure that the resource is aware of this 
specification.


Are servers required to perform any actions related to preflight 
requests other than responding appropriately to them?


-Terence Bandoian


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



Re: Setup Issue tomcat 6 SLES 11 SSL

2014-04-30 Thread Terence M. Bandoian

On 4/30/2014 9:02 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Vincent,

On 4/29/14, 4:24 PM, Vincent T. DiScipio wrote:

I have setup tomcat 6 on SLES 11 and secured the instance with an
external certificate if authority.  The following is occurring
from the same machine using both IE and Firefox:

http://servername.wooster.edu:8080works for both IE11 and
Firefox 29 and displays the index.html

https://servername.wooster.edu:8443  works for Firefox 29 and
displays the index.html

https://servername.wooster.edu:8443  does not work for IE11v
displays This page can't be displayed

I have changed the logging level to finest and do not see any
errors in the catalina.out.

Thoughts?  I have the same setup on another server and I believe
the files and permission levels are set the same.

What does your SSL configuration look like?

You could also use either sslscan from the CLI or go to
https://www.ssllabs.com/ssltest/ and use their online tool to examine
the site from the outside.

Perhaps you have a combination of protocols and ciphers that MSIE
can't handle.

- -chris



If the option is available, you might also try disabling the IE 
friendly error messages.  I'm not sure about IE 11, but it seems like 
previous versions displayed an error message with a reddish background 
if they were unable to authenticate a server with a given SSL 
certificate.  Was a certificate authority bundle supplied with the SSL 
certificate?  If so, is it installed and configured?  Were the SSL 
certificates on the both servers issued by the same company?


-Terence Bandoian


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



Re: CORS issue with Tomcat and Android Webview

2014-04-30 Thread Terence M. Bandoian

On 4/28/2014 3:21 PM, Konstantin Kolinko wrote:

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see accept-origin documented?  I see an init-param
named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to *, all CORS
requests should be allowed.  As I understand it, the W3C spec only
requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match
the
list of allowed origins when the list is unbounded.


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

 serialized-origin   = scheme :// host [ : port ]
 ; scheme, host, port from RFC 3986

Nothing says that host can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
file:// origin will be null.

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming
clients).

b) Specifically white-list the null origin.

c) Specifically white-list a file:// origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko



Hi, Konstantin-

I agree there is value in validating the origin header value and with your
interpretation of the IETF origin header specification.  I was referring to:

 http://www.w3.org/TR/cors/#resource-requests

which includes:

 1. If the Origin header is not present terminate this set of steps. The
request is outside the scope of this specification.

 2. If the value of the Origin header is not a case-sensitive match for
any of the values in list of origins, do not set any additional headers and
terminate this set of steps.

 Note: Always matching is acceptable since the list of origins can be
unbounded.

The solution you propose makes sense to me and I think will work although
I'm a little unclear about a).  Do you mean adding a test for a null host
value?

In a) I meant that  on Origin header is either null (4 characters literally),
or  scheme :// host [ : port ].

It is not an URI. So in theory the check can be more strict, that
there is no path, query, anchor or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko



One alternative solution might be to reduce origin header validation to 
checking for invalid characters only. It may be a little sloppy but 
would eliminate the need to add to a hardcoded whitelist for every 
client that doesn't comply with the origin header spec.


Another would be to add a cors.allowed.invalidorigins initialization 
parameter. This would allow for strict validation of origin headers with 
configurable whitelisting of invalid values.


-Terence Bandoian

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



Re: CORS issue with Tomcat and Android Webview

2014-04-28 Thread Terence M. Bandoian

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see accept-origin documented?  I see an init-param named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to *, all CORS
requests should be allowed.  As I understand it, the W3C spec only requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match the
list of allowed origins when the list is unbounded.


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

serialized-origin   = scheme :// host [ : port ]
; scheme, host, port from RFC 3986

Nothing says that host can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
file:// origin will be null.

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming clients).

b) Specifically white-list the null origin.

c) Specifically white-list a file:// origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko




Hi, Konstantin-

I agree there is value in validating the origin header value and with 
your interpretation of the IETF origin header specification.  I was 
referring to:


http://www.w3.org/TR/cors/#resource-requests

which includes:

1. If the Origin header is not present terminate this set of steps. 
The request is outside the scope of this specification.


2. If the value of the Origin header is not a case-sensitive match 
for any of the values in list of origins, do not set any additional 
headers and terminate this set of steps.


Note: Always matching is acceptable since the list of origins 
can be unbounded.


The solution you propose makes sense to me and I think will work 
although I'm a little unclear about a).  Do you mean adding a test for a 
null host value?


-Terence Bandoian

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



Re: CORS issue with Tomcat and Android Webview

2014-04-28 Thread Terence M. Bandoian

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com:

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian tere...@tmbsw.comwrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So shouldn't CORS
filter honor this ?

I agree that Client also has the problem , but still server should also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards




Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple 
requests.


-Terence Bandoian


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



Re: CORS issue with Tomcat and Android Webview

2014-04-28 Thread Terence M. Bandoian

On 4/28/2014 3:21 PM, Konstantin Kolinko wrote:

2014-04-28 23:44 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/27/2014 11:36 AM, Konstantin Kolinko wrote:

2014-04-27 0:50 GMT+04:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian

Hi, Ankit-

Where did you see accept-origin documented?  I see an init-param
named
cors.allowed.origins on the Tomcat web site:

https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter

In any case, I agree that if allowed origins is set to *, all CORS
requests should be allowed.  As I understand it, the W3C spec only
requires
that the Origin header exists:

http://www.w3.org/TR/cors/#resource-processing-model

It also states that it is acceptable for Origin headers to always match
the
list of allowed origins when the list is unbounded.


1. From a quick reading, I do not see any syntax for that lists
besides exact case-sensitive matches.

http://tools.ietf.org/html/rfc6454#section-7
says that the syntax of origin header is

 serialized-origin   = scheme :// host [ : port ]
 ; scheme, host, port from RFC 3986

Nothing says that host can be omitted.

http://tools.ietf.org/html/rfc6454#section-6.1
Per Sections 6.1 and 6.2 the correct serialized value of such
file:// origin will be null.

2. Some form of sanity check must be present,
because the origin header value is sent back to client and as such can
be abused.

3. That said,
I think that CorsFilter.isValidOrigin(String) can be patched to
a) Be more strict to the specified syntax  (and not just allow any URI)
(Not actually necessary, but it will allow to reject non-conforming
clients).

b) Specifically white-list the null origin.

c) Specifically white-list a file:// origin,  with notion that that
is a bug in certain Android versions


Maybe this is a good case to submit a bug report or a patch.

Agreed.

Best regards,
Konstantin Kolinko



Hi, Konstantin-

I agree there is value in validating the origin header value and with your
interpretation of the IETF origin header specification.  I was referring to:

 http://www.w3.org/TR/cors/#resource-requests

which includes:

 1. If the Origin header is not present terminate this set of steps. The
request is outside the scope of this specification.

 2. If the value of the Origin header is not a case-sensitive match for
any of the values in list of origins, do not set any additional headers and
terminate this set of steps.

 Note: Always matching is acceptable since the list of origins can be
unbounded.

The solution you propose makes sense to me and I think will work although
I'm a little unclear about a).  Do you mean adding a test for a null host
value?

In a) I meant that  on Origin header is either null (4 characters literally),
or  scheme :// host [ : port ].

It is not an URI. So in theory the check can be more strict, that
there is no path, query, anchor or whatever additional URI
components can be there.

(Though I see no real worth in being that strict. A small worth is to
encourage clients to behave correctly, if there are some misbehaving
ones).

Best regards,
Konstantin Kolinko



Ahh.  Makes sense.  Thanks for the clarification.

-Terence Bandoian


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



Re: CORS issue with Tomcat and Android Webview

2014-04-28 Thread Terence M. Bandoian

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com:

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
tere...@tmbsw.comwrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So shouldn't
CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards



Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at 
all.  Can you point me to where you've found that?


-Terence Bandoian


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



Re: CORS issue with Tomcat and Android Webview

2014-04-28 Thread Terence M. Bandoian

On 4/28/2014 5:32 PM, Terence M. Bandoian wrote:

On 4/28/2014 3:08 PM, Jose María Zaragoza wrote:

2014-04-28 21:55 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/26/2014 6:56 AM, Jose María Zaragoza wrote:

2014-04-26 13:16 GMT+02:00 Martin Gainty mgai...@hotmail.com:

Date: Sat, 26 Apr 2014 11:43:05 +0530
Subject: Re: CORS issue with Tomcat and Android Webview
From: ankising...@gmail.com
To: users@tomcat.apache.org

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian
tere...@tmbsw.comwrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see 
the

headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So 
shouldn't

CORS
filter honor this ?

I agree that Client also has the problem , but still server should
also
allow...


Hi:

I'm watching this flowchart
https://tomcat.apache.org/tomcat-7.0-doc/images/cors-flowchart.png

and I wonder if Tomcat 7 checks if the request received belongs to the
right type.
I mean, if browser sends a simple request ( eg. POST + application/xml
content-type header )
WC3 spec says that request should be a preflight request  , does
Tomcat check this case ?



Regards



Hi, Jose-

I don't see where the W3C spec requires a preflight request for simple
requests.


-Terence Bandoian


Sorry, I meant non-simple request.
For example, if I perform a cross-domain POST request (within
application/xml content-type header ),
I guess that a preflight request is required , right ?
What happens, if it's not sent , on Tomcat? Should it check it ?

Regards



Hi, Jose-

I don't see in the W3C spec where preflight requests are required at 
all.  Can you point me to where you've found that?


-Terence Bandoian




I meant to say I don't see where the W3C spec requires preflight 
requests to be sent.


-Terence


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



Re: CORS issue with Tomcat and Android Webview

2014-04-26 Thread Terence M. Bandoian

On 4/26/2014 1:13 AM, Ankit Singhal wrote:

On Sat, Apr 26, 2014 at 12:53 AM, Terence M. Bandoian tere...@tmbsw.comwrote:


On 4/24/2014 11:16 PM, Ankit Singhal wrote:


Hi

I did more research on this and figure out the issue.If you see the
headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and
considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So shouldn't CORS
filter honor this  ?

I agree that Client also has the problem  , but still server should also
allow...



Hi, Ankit-

Have you tried disabling or removing the CORS filter when you're testing
from the Android device?  The flowchart in the Tomcat CORS documentation
indicates that the filter will attempt to validate the origin before it
determines whether or not it is allowed. Apparently, the file scheme is not
considered valid.

Please Note:  The convention on this list is to bottom-post.  When you
reply to a message, please do so at the bottom of the message or inline, as
I've done here.  Additional information may be found on the Tomcat web
site: http://tomcat.apache.org/lists.html#tomcat-users

Hope that helps.

-Terence Bandoian





On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian tere...@tmbsw.com

wrote:

  On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:

  2014-04-24 19:00 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

  On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

  -- Forwarded message --

From: Terence M. Bandoian tere...@tmbsw.com
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List users@tomcat.apache.org


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

  Also we tried to give the same call from Android App to some

different
Node
server and things worked fine. So it seems some problem with Tomcat
only.

   A silly question:


What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me
to
follow but basically, requests to Tomcat are successful when tested
with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request
processing
by
the Tomcat CORS filter? If it were me, I'd find out.

  Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a not simple
request ( sic. ) and it requires a OPTIONS preflight request (
including Origin header)
And Once the preflight request gives permissions, the browser makes
the actual request

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

  From the page you cited:

The use-case for CORS is simple. Imagine the site alice.com has some
data that the site bob.com wants to access. This type of request
traditionally wouldn’t be allowed under the browser’s same origin policy.
However, by supporting CORS requests, alice.com can add a few special
response headers that allows bob.com to access the data.

In this case, alice.com would be the server that hosts Tomcat.  As you
suggest, the problem may very well be in the client but - FOR ME - it's
worth the effort to understand what should happen on both the client and
the server and to ensure that both are configured correctly.

-Terence Bandoian





   On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal


ankising...@gmail.comwrote:

   Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am
developing
a
Hybrid web app using ionicframework, AngularJS, Cordova as front end
and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome ,
where
things are working fine. I added CORS filter with standard
configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX
calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers

Re: CORS issue with Tomcat and Android Webview

2014-04-25 Thread Terence M. Bandoian

On 4/24/2014 11:16 PM, Ankit Singhal wrote:

Hi

I did more research on this and figure out the issue.If you see the headers
from Android and look into Origin Header.

Origin: file://

Tomcat CORS filter tries to validate the URI in Origin header and considers
file:// as an invalid URI and returns back 403.

I have applied accept-origin*/accept-origin params. So shouldn't CORS
filter honor this  ?

I agree that Client also has the problem  , but still server should also
allow...



Hi, Ankit-

Have you tried disabling or removing the CORS filter when you're testing 
from the Android device?  The flowchart in the Tomcat CORS documentation 
indicates that the filter will attempt to validate the origin before it 
determines whether or not it is allowed. Apparently, the file scheme is 
not considered valid.


Please Note:  The convention on this list is to bottom-post.  When you 
reply to a message, please do so at the bottom of the message or inline, 
as I've done here.  Additional information may be found on the Tomcat 
web site: http://tomcat.apache.org/lists.html#tomcat-users


Hope that helps.

-Terence Bandoian






On Fri, Apr 25, 2014 at 1:36 AM, Terence M. Bandoian tere...@tmbsw.comwrote:


On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:


2014-04-24 19:00 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:


On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:


-- Forwarded message --
From: Terence M. Bandoian tere...@tmbsw.com
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List users@tomcat.apache.org


On 4/22/2014 11:03 AM, Ankit Singhal wrote:


Also we tried to give the same call from Android App to some different
Node
server and things worked fine. So it seems some problem with Tomcat
only.

  A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me
to
follow but basically, requests to Tomcat are successful when tested with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request processing
by
the Tomcat CORS filter? If it were me, I'd find out.


Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a not simple
request ( sic. ) and it requires a OPTIONS preflight request (
including Origin header)
And Once the preflight request gives permissions, the browser makes
the actual request

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

 From the page you cited:

The use-case for CORS is simple. Imagine the site alice.com has some
data that the site bob.com wants to access. This type of request
traditionally wouldn’t be allowed under the browser’s same origin policy.
However, by supporting CORS requests, alice.com can add a few special
response headers that allows bob.com to access the data.

In this case, alice.com would be the server that hosts Tomcat.  As you
suggest, the problem may very well be in the client but - FOR ME - it's
worth the effort to understand what should happen on both the client and
the server and to ensure that both are configured correctly.

-Terence Bandoian





  On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal

ankising...@gmail.comwrote:

  Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing
a
Hybrid web app using ionicframework, AngularJS, Cordova as front end
and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard
configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX
calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q

Re: CORS issue with Tomcat and Android Webview

2014-04-24 Thread Terence M. Bandoian

On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

-- Forwarded message --
From: Terence M. Bandoian tere...@tmbsw.com
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List users@tomcat.apache.org


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.



A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me 
to follow but basically, requests to Tomcat are successful when tested 
with Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful 
when tested from an Android device. What are the differences between the 
two environments? Do those differences have any effect on request 
processing by the Tomcat CORS filter? If it were me, I'd find out.


-Terence Bandoian





On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal ankising...@gmail.comwrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=F-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 HTTP/1.1http://medistreet.in/auth2%20HTTP/1.1

Accept: application/json, text/plain, */*

Origin: file://

User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
Safari/537.36

Content-Type: application/json;charset=F-8





The difference here I see is with Number of headers and specially Origin
Header  which contains file://. To overcome this I added  more option
is CORS filter:



filter

filter-nameCorsFilter/filter-name

filter-classorg.apache.catalina.filters.CorsFilter/filter-class

init-param

param-namecors.allowed.origins/param-name

param-value*/param-value

/init-param

/filter

filter-mapping

filter-nameCorsFilter/filter-name

url-pattern/*/url-pattern

/filter-mapping



Another strange thing is that when we send the same Android request
Headers from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=F-8

Cookie:fbm_464284963672217�se_domain=.medistreet.in;
JSESSIONID�435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=jASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsN

Re: CORS issue with Tomcat and Android Webview

2014-04-24 Thread Terence M. Bandoian

On 4/24/2014 1:14 PM, Jose María Zaragoza wrote:

2014-04-24 19:00 GMT+02:00 Terence M. Bandoian tere...@tmbsw.com:

On 4/22/2014 1:37 PM, Jose María Zaragoza wrote:

-- Forwarded message --
From: Terence M. Bandoian tere...@tmbsw.com
Date: 2014-04-22 20:12 GMT+02:00
Subject: Re: CORS issue with Tomcat and Android Webview
To: Tomcat Users List users@tomcat.apache.org


On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different
Node
server and things worked fine. So it seems some problem with Tomcat only.


A silly question:

What does it have to do Tomcat's CORS support with W3C Widget Access
specification ?

I have no idea about Phonegap but it looks like that it prefers to
follow that specification for managing requests to different domains ,
right ?



Hi, Jose-

The request/response headers in the original post were difficult for me to
follow but basically, requests to Tomcat are successful when tested with
Chrome (desktop? laptop? server? same as Tomcat?) and unsuccessful when
tested from an Android device. What are the differences between the two
environments? Do those differences have any effect on request processing by
the Tomcat CORS filter? If it were me, I'd find out.


Well , I have no idea, but according this page

http://www.html5rocks.com/en/tutorials/cors/

if Content-Type is application/json , then request is a not simple
request ( sic. ) and it requires a OPTIONS preflight request (
including Origin header)
And Once the preflight request gives permissions, the browser makes
the actual request

First case (Chrome browser) did but, but the second didn't

Are you test to change the Content-Type ?

Regards



Hi, Jose-

From the page you cited:

The use-case for CORS is simple. Imagine the site alice.com has some 
data that the site bob.com wants to access. This type of request 
traditionally wouldn’t be allowed under the browser’s same origin 
policy. However, by supporting CORS requests, alice.com can add a few 
special response headers that allows bob.com to access the data.


In this case, alice.com would be the server that hosts Tomcat.  As you 
suggest, the problem may very well be in the client but - FOR ME - it's 
worth the effort to understand what should happen on both the client and 
the server and to ensure that both are configured correctly.


-Terence Bandoian







On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal
ankising...@gmail.comwrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration
to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls
to
tomcat server. To my surprise things stopped working . I debugged
further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=






POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=8


Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36
(KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2
HTTP/1.1http://medistreet.in/auth2%20HTTP/1.1

Accept: application/json, text/plain, */*

Origin: file://

User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033
Build/KXB20.25-1.31)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0
Mobile
Safari/537.36

Content-Type: application/json;charset=8






The difference here I see is with Number of headers and specially Origin
Header  which contains file://. To overcome this I added  more option
is CORS filter:



filter

filter-nameCorsFilter/filter-name

Re: lean and mean Tomcat 7 configuration

2014-04-24 Thread Terence M. Bandoian

On 4/24/2014 10:52 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

André,

On 4/24/14, 9:16 AM, André Warnier wrote:

Starting from a vanilla current Tomcat 7 download (*), on a Linux
server

I have looked at the on-line Configuration documentation of Tomcat
7, but that kind of information is not really provided there.

We would like to configure this tomcat to be as lean and mean as
possible, within the following parameters :

Strong suggestion: use a separate CATALINA_BASE if you aren't already
doing so. I'm not sure how complicated this is to do with Debian's
package-managed version of Tomcat.


- it only needs one default Host

Default.


- we do not use the Manager

Default.


- it is running a single webapp, which has only a few servlets and
no JSP pages at all.

Easy: dump your WAR in the right place. Remove the ROOT WAR (or
replace it).


- the application is never deployed/undeployed live; when we make
a change, we always restart Tomcat - all accesses to Tomcat happen
through an Apache httpd front-end on the same host, via mod_jk and
Tomcat's AJP Connector - there is no authentication done at the
Tomcat level; if AAA is done, it is done at the httpd level and
passed on via mod_jk

Ok.


- there is no need for an Access log (we have one at the Apache
httpd front-end level)

The access log is sometimes useful. Disabling it is easy, though.


- the running webapp does not leak memory, does not start
ThreadLocal's (whatever that is) - we do not need SSL (so do we
need APR ? does it bring anything in this case ?)

APR will not really help you. I would recommend using the BIO
connector since you are using only AJP from httpd. If you need to
handle many many incoming AJP connections, perhaps the NIO connector
would be better.


- the request volume is low, in relation to what I see sometimes
being mentioned on this Users List (say peak may be 10 per second,
and it does not happen often)

Ok.


- we would like only one logfile, for everything which Tomcat
itself produces (currently, it seems to produce half a dozen, most
of them empty but nevertheless rotated on a daily base)

The default logging.properties creates lots of log files. Feel free to
remove/customize it. By not deploying additional applications
(host-manager, manager, etc.), you may get some log files created but
never containing any logs. Just remove/comment those from
logging.properties.


- we would like a separate logfile for the one webapp, because it
unfortunately produces a bunch of junk output to sysout and/or
syserr, and there is no way to turn that off at the webapp level,
and we do not have the source code of that webapp.

swallowOutput=true, and configure the logger in logging.properties.


(Basically, I would like to junk this output to /dev/null, but
how do I do that with the standard Tomcat JULI logging ?)

Umm... I'm not sure. Does JULI have a DevNullLogger? I'd have to look.


So basically, what can we remove from the standard server.xml and
the standard logging.properties, and which may be meaningful to
remove ?

I would generally leave server.xml alone. Nothing in there will slow
you down, etc. If you are passionate about it, remove the AccessLogValve.

logging.properties is another story. I would comment-out anything
related to the web applications you are /not/ deploying (e.g.
host-manager, manager, etc.) and add something for your own
application so the logs so somewhere other than catalina.out (or
wherever Debian puts it). Then you can figure out whether or not there
is a /dev/null logger you can use. Perhaps you can use a standard file
logger and point it at /dev/null. (Why don't you want your logs?)


I am starting from the premise that whatever ones adds, uses some
resources in some way. But I also do not want to spend hours
wringing the last 1 KB out of memory; 1 MB might be worthwhile
though, specially if it is there for each running webapp instance.

Most of the stuff in server.xml are lifecycle listeners that do
something on startup and generally don't do anything after that. The
memory leak checking stuff only really affects you on shutdown and
will tell you if you have any problems. Again, if you feel passionate,
you can pretty much remove them all (except for Jasper, if you use any
JSPs).



Even if you do use JSP, you may be able to remove the Jasper listener if 
you pre-compile the JSPs at build time and only deploy the generated 
classes.


-Terence Bandoian





For example, in the standard server.xml, there are the following
Listeners listed at the beginning : Listener
className=org.apache.catalina.core.AprLifecycleListener
SSLEngine=on /

Does nothing if APR is not installed. No runtime impact except that
the AprLifecycleListener class is loaded into memory and there is an
instance of it laying around.


Listener className=org.apache.catalina.core.JasperListener /

Enables JSP. Required if you want JSPs. Oddly enough, the reference in
the config file for 

Re: CORS issue with Tomcat and Android Webview

2014-04-22 Thread Terence M. Bandoian

On 4/22/2014 11:03 AM, Ankit Singhal wrote:

Also we tried to give the same call from Android App to some different Node
server and things worked fine. So it seems some problem with Tomcat only.


On Tue, Apr 22, 2014 at 9:22 PM, Ankit Singhal ankising...@gmail.comwrote:


Hi All



I am facing a strange problem with Tomcat 8 and CORS. I am developing a
Hybrid web app using ionicframework, AngularJS, Cordova as front end and
Tomcat 8 and Spring 3 as back-end.



For easy development I am testing the functionality in chrome , where
things are working fine. I added CORS filter with standard configuration to
allow CROSS ORIGIN requests from browser.



Today I converted my app into Android App and started making AJAX calls to
tomcat server. To my surprise things stopped working . I debugged further
and anomalies in the headers of browser and Android webview.



Browser sends 2 requests for same call OPTION and POST. But Android
Webview only send POST request.



Browser Request Headers:



OPTION:

Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:OPTIONS

Status Code:200 OK

Request Headers

OPTIONS /auth2 HTTP/1.1

Host: medistreet.in

Connection: keep-alive

Access-Control-Request-Method: POST

Origin: http://localhost

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36

Access-Control-Request-Headers: accept, content-type

Accept: */*

Referer: http://localhost/

Accept-Encoding: gzip,deflate,sdch

Accept-Language: en-US,en;q=0.8





POST:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK



Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Host:medistreet.in

Origin:http://localhost

Referer:http://localhost/

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





Android Request Headers:



Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:403 Forbidden

Request Headers

POST http://medistreet.in/auth2 HTTP/1.1http://medistreet.in/auth2%20HTTP/1.1

Accept: application/json, text/plain, */*

Origin: file://

User-Agent: Mozilla/5.0 (Linux; Android 4.4.2; XT1033 Build/KXB20.25-1.31)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile
Safari/537.36

Content-Type: application/json;charset=UTF-8





The difference here I see is with Number of headers and specially Origin
Header  which contains file://. To overcome this I added  more option
is CORS filter:



filter

filter-nameCorsFilter/filter-name

filter-classorg.apache.catalina.filters.CorsFilter/filter-class

init-param

param-namecors.allowed.origins/param-name

param-value*/param-value

/init-param

/filter

filter-mapping

filter-nameCorsFilter/filter-name

url-pattern/*/url-pattern

/filter-mapping



Another strange thing is that when we send the same Android request
Headers from POSTMAN (chrome REST plugin) request is successful.



POSTMAN Headers:



Remote Address:54.254.159.166:80

Request URL:http://medistreet.in/auth2

Request Method:POST

Status Code:200 OK

Request Headers

Accept:application/json, text/plain, */*

Accept-Encoding:gzip,deflate,sdch

Accept-Language:en-US,en;q=0.8

Cache-Control:no-cache

Connection:keep-alive

Content-Length:39

Content-Type:application/json;charset=UTF-8

Cookie:fbm_464284963672217=base_domain=.medistreet.in;
JSESSIONID=87435755F03D7B045DD6E33D1D16AC51;
fbsr_464284963672217=dUjASqF-nWquTFPk_-5wAtI0jTImBNkVxglUT-gHNSw.eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsImNvZGUiOiJBUUQ0UEZZVXE4eDFIa3V6OW9RV3RlVzE4clQ3SmtVRjBzU1VVcXhfV1BENG8tV1BZYjZuTVdDdDJGMmw4TjJUeUxLSzhIYUU1TUc2MkY5cXZOaXRMN3NGdklNZkhySmluYkdjMWs1THAyZnZYa2Zpa1lLVGJ0OWlZeXVvRDNWUDhTblp4czJCeTQ4RTlYY1ZjUmhGWGJsNnFMeG5YcWxxQ0d3b0hRM1ctRWhlLU02ejVITnhhakJtaVFRVk9PanFBVUtMSlk4Y3pLa0RtejFSY3RjTEFRaW16X1lkLUFkUngxUGwzajVNczdWOFdiMW9xeC05QjA0T2xraXktVU9ZalpSRUJsZjhibnZjQXQ2aUZTc1d2QTA3TjVUYnFIekVxQ0JIYjJNRG4tSUJhajl6TEMwQlVpckM0YzJXbC1GVDNhcyIsImlzc3VlZF9hdCI6MTM5ODE4MDg2NCwidXNlcl9pZCI6IjU3NjI1MjI2MiJ9

Host:medistreet.in

Origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm

User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/34.0.1847.116 Safari/537.36





After this also there is no solution to the problem .  I suspect that
Android Webview is not sending something which Tomcat is rejecting.



Any help will highly be appreciated.


Regards

Ankit



Hi, Ankit-

I would double-check the documentation for the Tomcat CORS filter and 
the Cordova whitelist implementation:


https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter
http://docs.phonegap.com/en/3.4.0/guide_appdev_whitelist_index.md.html

Hope that helps.

-Terence Bandoian



Re: Configuration question

2014-04-17 Thread Terence M. Bandoian

On 4/17/2014 9:01 AM, Mark Murphy wrote:

Here is the configuration, as you can see the default host is set and the
IP is not aliased.

in server.xml
...
 Connector port=80 protocol=HTTP/1.1
connectionTimeout=2
redirectPort=443 /
...
 Connector protocol=org.apache.coyote.http11.Http11NioProtocol
port=443
scheme=https secure=true SSLEnabled=true
keystoreFile=xxx.keystore
keystorePass=xxx keyAlias=xxx
clientAuth=false sslProtocol=TLS /
...
 Engine name=Catalina defaultHost=www.torquewrenchrecalibration.com
...
   Host name=www.torquewrenchrecalibration.com  appBase=webapps
 unpackWARs=true autoDeploy=false
 xmlValidation=false xmlNamespaceAware=false
 Aliaswww.torque-wrench-recalibration.com/Alias
 Aliaswww.myerstorquetracker.com/Alias
   /Host
...

in web.xml
...
 security-constraint
   web-resource-collection
 web-resource-nameEntire App/web-resource-name
 url-pattern/*/url-pattern
   /web-resource-collection
   user-data-constraint
 transport-guaranteeCONFIDENTIAL/transport-guarantee
   /user-data-constraint
 /security-constraint
...



On Thu, Apr 17, 2014 at 9:42 AM, Jeffrey Janner jeffrey.jan...@polydyne.com

wrote:

-Original Message-
From: Mark Murphy [mailto:jmarkmur...@gmail.com]
Sent: Wednesday, April 16, 2014 12:42 PM
To: Tomcat Users List
Subject: Configuration question

How do I prevent Tomcat 6 from responding to a request to an IP
address, that is I only want my Tomcat server to respond to requests to
www.mydomain.com vs. 10.1.1.1.

Is this possible?


To address the question asked:
The easiest way may be to create a dummy Host entry with an Alias
entry for the IP Address. Do not allocate any contexts to the host, or
perhaps one that points to an empty directory.  Haven't tested it, just a
thought.
However read rest of answer.


The problem is that our web security scanner is reporting Web Server
Uses Basic Authentication Without HTTPS, and the infrastructure guys
think it is because Tomcat allows connection to the IP address.

Does this make sense?

No this does not make sense.  If the IP isn't returning HTTPS, then your
DNS name probably isn't either. Tomcat doesn't care about the supplied
name, except to match it to the Host entry in server.xml.  You didn't
post your config, but I'm assuming that the default host is set to
www.mydomain.com, and the IP address isn't aliased. If it is not that
way, you should either correctly set your default host, or add an Alias
entry for the IP address to you Host config.

You'd definitely get this response if your default host was still set at
the default of localhost, instead of your Host entry's name value,
there was no Alias entry for the IP, and the security tester was testing
against IP as well as name (though one would expect the report to indicate
this).



Is the manager app deployed?

-Terence Bandoian


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



Re: AW: AW: tomcat-connectors-1.2.39-windows-x86_64-iis does not work

2014-04-04 Thread Terence M. Bandoian

On 4/4/2014 5:52 PM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 4/4/14, 1:09 PM, Jeffrey Janner wrote:

-Original Message- From: Jeffrey Janner
[mailto:jeffrey.jan...@polydyne.com] Sent: Friday, April 04, 2014
12:04 PM To: 'Tomcat Users List' Subject: RE: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work


-Original Message- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Friday, April 04,
2014 10:23 AM To: Tomcat Users List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

Jeffrey,

On 4/4/14, 10:50 AM, Jeffrey Janner wrote:

-Original Message- From: André Warnier
[mailto:aw@ice-

sa.com]

Sent: Thursday, April 03, 2014 5:27 PM To: Tomcat Users
List Subject: Re: AW: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does not work

Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256

André,

On 4/3/14, 3:34 PM, André Warnier wrote:

Alten, Jessica-Aileen wrote:

-Ursprüngliche Nachricht- Von: André
Warnier [mailto:a...@ice-sa.com] Gesendet:
Donnerstag, 3. April 2014 15:36 An: Tomcat Users
List Betreff: Re: AW:
tomcat-connectors-1.2.39-windows-x86_64-iis does
not work

Alten, Jessica-Aileen wrote:

A bit guessing here :

You have :

worker.ajp13w.host=localhost

and


jk_open_socket::jk_connect.c (735): connect
to 0.0.0.0:8009

failed

(errno=49)

is localhost == 0.0.0.0  ?

 From the point of view of mod_jk/isapi, should
it not be

127.0.0.1 ?

Your answer points to the right direction.
0.0.0.0 means: any configured IPv4-Address on
this computer, see

http://serverfault.com/questions/78048/whats-the-difference-

betwee

n-

ip

-addre ss-0-0-0-0-and-127-0-0-1

In principle this is ok at first. The Ajp13
Connector was configured in server.xml to listen
at any IPv4 address on

port

8009 - which is the default setting. But the
connector can't find any suitable

address.

The problem is: The new Tomcat-Connector can't
parse worker.ajp13w.host=localhost, instead
localhost must be

replaced

with 127.0.0.1, this works!

In my eyes this is a big fat bug, because most
documentation on workers use localhost.
localhost is actually the default for

the

host connection directive.

The new worker directive prefer_ipv6 doesn't
change this behavior.


Hi.

Can you please really check this ?

Open a command window on that server, and do ping
localhost.

It

should tell you what it understands by localhost.
Copy and paste the result here :

ping localhost

Ping wird ausgeführt für xyz.uv.local [127.0.0.1] mit
32 Bytes Daten: Antwort von 127.0.0.1: Bytes=32
Zeit1ms TTL=128 Antwort von 127.0.0.1: Bytes=32
Zeit1ms TTL=128

Antwort

von 127.0.0.1: Bytes=32 Zeit1ms TTL=128 Antwort von
127.0.0.1: Bytes=32 Zeit1ms TTL=128

Ping-Statistik für 127.0.0.1: Pakete: Gesendet = 4,
Empfangen =

4,

Verloren = 0 (0% Verlust), Ca. Zeitangaben in
Millisek.:

Minimum

=

0ms, Maximum = 0ms, Mittelwert = 0ms



That /is/ bizarre.  As far as I know, to resolve
hostnames in

its

configuration, mod_jk/isapi is using the OS's resolver
library,

the

same as the one ping should be using. On the other
hand, you say that if you have


worker.ajp13w.host=localhost

it doesn't work (mod_jk cannot connect to tomcat), but
when you change this to


worker.ajp13w.host=127.0.0.1

then it works fine.

Ok, another check in a command window (and I assume
that you

open

this command window *on the server itself* where mod_jk
and Tomcat are running, right ?)

test :

1) telnet localhost 8009

2) telnet 127.0.0.1 8009

Any difference between these 2 cases ?

If not, then indeed it looks like a
mod_jk/isapi_redirect 1.2.39 problem.

In any case, you cannot connect to 0.0.0.0, as this
log line would suggest :


jk_open_socket::jk_connect.c (735): connect
to 0.0.0.0:8009

failed

Could this be an interaction between IPv4 and IPv6? Try:

C: nslookup localhost

You might get only 127.0.0.1 or you might also get ::
(or something equivalent). I'm not sure why it wasn't
happening with earlier versions of mod_jk (which?).


(versions : her first post mentioned the versions she was
comparing)

I previously asked Jessica-Aileen to do a ping localhost
on the machine, see results above.  It definitiely pings
127.0.0.1 .. (assuming it was done on the same machine)

And I don't think that nslookup uses the local resolver.
When I'm doing that on my Windows laptop, for localhost
it responds not found (in many more German words)

C:\Dokumente und Einstellungen\awnslookup localhost
Server: fire-see.localdomain Address:  192.168.245.253

*** localhost wurde von fire-see.localdomain nicht
gefunden: Non- existent domain

On the other hand, it does this (spot the difference..):

C:\Dokumente und Einstellungen\awnslookup localhost.
Server: fire-see.localdomain Address:  192.168.245.253

Name:localhost Address:  127.0.0.1

(But that of course could be the 

Re: Tomcat 7 : Configure redirect url for session timeout

2014-03-16 Thread Terence M. Bandoian

On 3/14/2014 6:18 PM, Akash Jain wrote:

I want to redirect user to / with a query parameter to indicate that
session has timed out.


On Fri, Mar 14, 2014 at 4:01 PM, Leo Donahue donahu...@gmail.com wrote:


On Fri, Mar 14, 2014 at 3:48 PM, Akash Jain akash.delh...@gmail.com
wrote:
Leo,
If any request comes after session timeout interval ... why would it go

into error ?

Perhaps because the request/response that was created with a session is no
longer valid after the session timeout.  What other option would you have
if not an error-page?



Hi, Akash-

Seems like a fairly simple filter could handle this by redirecting to 
the home page if the session is invalid and the home page isn't already 
the target.


-Terence Bandoian


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



  1   2   3   >