Re: [EXTERNAL] Using CLIENT-CERT

[Amit Pande]

Thank you so much Chris and Mark! Sincerely appreciate the inputs.

Sent from my iPhone

> On Apr 11, 2018, at 8:16 AM, Christopher Schultz 
>  wrote:
> 
> Mark and Amit,
> 
>> On 4/10/18 2:21 AM, Mark Thomas wrote:
>>> On 9 April 2018 23:29:43 BST, Amit Pande  wrote:
>>> Some more debugging here and I got some stuff working here.
>>> 
>>> Only one question:
>>> 
>>> It is not really clear from the documentation of "clientAuth"
>>> 
>>> "Set to true if you want the SSL stack to require a valid certificate
>>> chain from the client before accepting a connection. Set to want if you
>>> want the SSL stack to request a client Certificate, but not fail if one
>>> isn't presented. A false value (which is the default) will not require
>>> a certificate chain unless the client requests a resource protected by
>>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>>> HowTo for an example. That SSL HowTo also contains tips on using
>>> per-user or per-session certificate-based clientAuth."
>>> 
>>> So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>>> configuration, does that mean browsers won't prompt users to supply the
>>> certificate when a protected resource is accessed?
>> 
>> In that scenario the browser will prompt the user for a certificate if 
>> everything is correctly configured.
>> 
>> However, it is possible that the browser will determine that it has no 
>> matching certificates and therefore decide not to display the certificate 
>> prompt.
> 
> Also, sometimes browsers will "remember" your choice from a prior
> interaction during the same browser session. So for example if you have
> clientAuth="want" and you press "No/Cancel/[escape]/[close window]" the
> browser may "remember" that you don't want to present a certificate.
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

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

RE: CrawlerSessionManagerValve only working with default host

[Matt Cosentino]

I first noticed it by the large number of sessions in the manager webapp, but 
then I verified it in my logs. Both of my sites are polled every minute by the 
UptimeRobot service. These requests are logged and I can see what session is 
being used. For the default host site, they reuse the same session. For the 
non-default host sites, they create new sessions.

04-11 00:00:14 INFO  LogRequest   >  HEAD: https www.defaulthost.com /, 
FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.defaulthost.com
04-11 00:01:14 INFO  LogRequest   >  HEAD: https www.defaulthost.com /, 
FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.defaulthost.com
04-11 00:02:14 INFO  LogRequest   >  HEAD: https www.defaulthost.com /, 
FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.defaulthost.com
04-11 00:03:13 INFO  LogRequest   >  HEAD: https www.defaulthost.com /, 
FROM: 69.162.124.237, D21FE7FD2B82B776AB194C278244D79E, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.defaulthost.com

04-11 00:00:32 INFO  LogRequest   >  HEAD: https www.anotherhost.com /, 
FROM: 69.162.124.237, C62DCA4E9DC39884E3E82EE19AAEAB4A, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.anotherhost.com
04-11 00:01:32 INFO  LogRequest   >  HEAD: https www.anotherhost.com /, 
FROM: 69.162.124.237, 542027513FD08CD82C8BEFF3C4E75F8C, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.anotherhost.com
04-11 00:02:32 INFO  LogRequest   >  HEAD: https www.anotherhost.com /, 
FROM: 69.162.124.237, F93C1929D880DDD446D13E36413544DF, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.anotherhost.com
04-11 00:03:32 INFO  LogRequest   >  HEAD: https www.anotherhost.com /, 
FROM: 69.162.124.237, 82C3BB415817B8C4761EFEF7EE7591DD, 
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/), 
REFERER: https://www.anotherhost.com

This is with the valve at the engine level, which I assumed meant that it would 
apply to all hosts within that engine. The documentation states "Normally, this 
Valve would be used at the Engine level.", so that's what I did.

https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Crawler_Session_Manager_Valve

- Matt

-Original Message-
From: Christopher Schultz  
Sent: Wednesday, April 11, 2018 1:46 PM
To: users@tomcat.apache.org
Subject: Re: CrawlerSessionManagerValve only working with default host

Matt,

On 4/11/18 2:03 PM, Matt Cosentino wrote:
> I have CrawlerSessionManagerValve set up at the Engine level, but it only 
> seems to be working for the default host and not any other host. Is this 
> expected behavior? Should I put it at the host level for each host?
> 
> Here is an example of how I have it set up:
> 
> 
>   
> 
>   
>   
>   
>className="org.apache.catalina.valves.CrawlerSessionManagerValve" 
> sessionInactiveInterval="300"/>
>
> 
> Tomcat 8.5.24

I don't see anything in the code that suggests it wouldn't work when used at 
the  level, but it also looks like it makes the most sense at the 
 level.

Can you describe your testing and the results you got?

When you say "only [...] working for the default host", do you mean that it 
works for the default host within an  (when configured at the  
level) or that it doesn't even work with a non-default  when configured 
at the  level?

-chris

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

Training material is now on-line

[Mark Thomas]

Hi all,

Thanks to the magic of GitHub pages, the Tomcat training material that
was used for the recent training session is now available on-line here:

https://apache.github.io/tomcat-training/

The source code is here:

https://github.com/apache/tomcat-training


We plan to add more modules and courses over time. All contributions
large and small welcome.

Enjoy.

Mark

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

Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

André,

On 4/11/18 5:47 PM, André Warnier (tomcat) wrote:
> On 11.04.2018 16:36, Christopher Schultz wrote:
>> André,
>>
>> On 4/10/18 11:38 AM, André Warnier (tomcat) wrote:
>>> Hi.
>>>
>>> On 10.04.2018 15:53, Christopher Schultz wrote:
 All,

 I've been asked to take some static files we already have on our
 (reverse-proxied) web servers and require authentication before
 allowing
 the resources to be fetched by a client.

 One way to do that would be to physically (electronically?) move the
 files from the web servers to the application servers, either as a part
 of the web application itself (tricky due to licensing issues of these
 documents) or as a separate set of files in an arbitrary place on the
 disk e.g. using .

 Before I do that, I was thinking that maybe I could point
  at a (private) URL that points back to the location
 where these files were already available. I was kind of hoping that
 simply doing http://static/files/here/;
 webAppMount="/static" /> or something like that.

 It looks like the existing WebResourceSet implementations are all
 disk-based resource providers.

 It also seems like writing a simple, read-only, "non-listable"
 implementation of an HTTPResourceSet might work for me.

 So I'm looking for opinions on what I should do, here. I might be able
 to hack-together an HttpResourceSet, but it probably won't benefit from
 e.g. range-requests (the files I am serving are PDFs, which often
 benefit from being able to perform range-requests) and might be
 fragile.

 I could move the files to the application servers, but then I need to
 make that a part of my app-server build process and I'd like that to
 remain as simple as possible.

 Finally, the files cannot go into revision-control due to licensing
 restrictions, so we basically have to keep them ... "safe" until they
 are deployed.

 Any ideas or suggestions?

>>>
>>> I know that when you have a hammer, everything looks like a nail but why
>>> not set up a separate Apache httpd webserver for these things, and have
>>> your reverse-proxies direct the calls there for them ?
>>
>> Well, my reverse-proxies are already httpd instances, so there's no need
>> for ANOTHER instance.
>>
>> The problem is that I need Tomcat to enforce
>> authentication/authorization for these resources.
> 
> Ah, but that is something which you did not mention before (that the
> authentication/authorization must be done by Tomcat).

I tried to mention that:

On 4/10/18 9:53 AM, Christopher Schultz wrote:
> I've been asked to take some static files we already have on our 
> (reverse-proxied) web servers and require authentication before
> allowing the resources to be fetched by a client.
I neglected to mention that "Tomcat is providing the
authentication/authorization, here". I guess I thought it was implied.
Apologies.

>> The reverse-proxy cannot do that, and neither can some other web
>> server that isn't in communication with Tomcat.
>>
>> Unless there is a mod_is_user_logged_in_to_tomcat that can ping Tomcat
>> to see if a user is indeed logged-in and then only serve the resource if
>> it gets back a positive response.
> 
> Exactly. That's not available off-the-shelf, but feasible at the Apache
> level.
> (In fact, I have something just like that (mod_perl based) which uses
> Tomcat as an "authenticator" for resources deployed at the Apache level).
> So let me know if your current solution is still unsatisfactory and you
> want to move these things back out from your app servers deployments.

Hah, it might be worth taking a look. Care to post the code somewhere?

>>> Or, use URLRewriteFilter to redirect these calls to wherever you want.
>>> I'm saying that because it doesn't really sound like you want to mix
>>> this up too much with your Java apps..
>>
>> Directing the traffic isn't the problem. Enforcing authentication is.
> 
> Thinking further about this, you are certainly not the only person who
> has that kind of requirement.
> And it would probably not be a big deal for the people who developed
> mod_proxy_ajp at the Apache httpd level, to create such an Apache httpd
> "authentication provider" based on tomcat as a back-end. (See :
> http://httpd.apache.org/docs/2.4/howto/auth.html).
> I'm just saying..

Are you raising your hand? ;)

-chris

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

Re: Virtual directories, PostResources, and DefaultServlet

[tomcat]

On 11.04.2018 16:36, Christopher Schultz wrote:

André,

On 4/10/18 11:38 AM, André Warnier (tomcat) wrote:

Hi.

On 10.04.2018 15:53, Christopher Schultz wrote:

All,

I've been asked to take some static files we already have on our
(reverse-proxied) web servers and require authentication before allowing
the resources to be fetched by a client.

One way to do that would be to physically (electronically?) move the
files from the web servers to the application servers, either as a part
of the web application itself (tricky due to licensing issues of these
documents) or as a separate set of files in an arbitrary place on the
disk e.g. using .

Before I do that, I was thinking that maybe I could point
 at a (private) URL that points back to the location
where these files were already available. I was kind of hoping that
simply doing http://static/files/here/;
webAppMount="/static" /> or something like that.

It looks like the existing WebResourceSet implementations are all
disk-based resource providers.

It also seems like writing a simple, read-only, "non-listable"
implementation of an HTTPResourceSet might work for me.

So I'm looking for opinions on what I should do, here. I might be able
to hack-together an HttpResourceSet, but it probably won't benefit from
e.g. range-requests (the files I am serving are PDFs, which often
benefit from being able to perform range-requests) and might be fragile.

I could move the files to the application servers, but then I need to
make that a part of my app-server build process and I'd like that to
remain as simple as possible.

Finally, the files cannot go into revision-control due to licensing
restrictions, so we basically have to keep them ... "safe" until they
are deployed.

Any ideas or suggestions?



I know that when you have a hammer, everything looks like a nail but why
not set up a separate Apache httpd webserver for these things, and have
your reverse-proxies direct the calls there for them ?


Well, my reverse-proxies are already httpd instances, so there's no need
for ANOTHER instance.

The problem is that I need Tomcat to enforce
authentication/authorization for these resources.


Ah, but that is something which you did not mention before (that the 
authentication/authorization must be done by Tomcat).


The reverse-proxy

cannot do that, and neither can some other web server that isn't in
communication with Tomcat.

Unless there is a mod_is_user_logged_in_to_tomcat that can ping Tomcat
to see if a user is indeed logged-in and then only serve the resource if
it gets back a positive response.


Exactly. That's not available off-the-shelf, but feasible at the Apache level.
(In fact, I have something just like that (mod_perl based) which uses Tomcat as an 
"authenticator" for resources deployed at the Apache level).
So let me know if your current solution is still unsatisfactory and you want to move these 
things back out from your app servers deployments.





Or, use URLRewriteFilter to redirect these calls to wherever you want.
I'm saying that because it doesn't really sound like you want to mix
this up too much with your Java apps..


Directing the traffic isn't the problem. Enforcing authentication is.



Thinking further about this, you are certainly not the only person who has that kind of 
requirement.
And it would probably not be a big deal for the people who developed mod_proxy_ajp at the 
Apache httpd level, to create such an Apache httpd "authentication provider" based on 
tomcat as a back-end. (See : http://httpd.apache.org/docs/2.4/howto/auth.html).

I'm just saying..


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

Re: Tomcat websocket server onclose failed( Tomcat 8.5)

[Mark Thomas]

On 11/04/18 09:50, Funian Li wrote:
>  Dear All,
> 
>   A problem happen when tomcat websocket server was used.

Exact Tomcat version?

If not 8.5.30, does the problem still occur if you upgrade to 8.5.30?

Mark


> 
>A sensor data chart with sampling freqency 50Hz is drawn. Tomcat
> websocket server( Version 8.5)  is used to push the data with 20ms
> interval. The server code is as following:
> 
> @ServerEndpoint("/websocketendpoint")public class WsServer {private
> Session session;private boolean keepingrunning;private static
> CopyOnWriteArraySet webSocketSet
>  = new  CopyOnWriteArraySet();
> @OnClosepublic void onClose() {
>   System.out.println("Close Connection ...");
>   keepingrunning = true;
>   webSocketSet.remove(this);}
> @OnOpenpublic void onOpen(Session session) {
>System.out.println("Open Connection ...");
>keepingrunning = true;
>this.session = session;
>webSocketSet.add(this);
>  }
> @OnMessagepublic void onMessage(String message, Session session) {
>   System.out.println("Message from the client: " + message);
>   try {
> Random r = new Random();
> // keep sending data
> while (keepingrunning) {
> int daf = r.nextInt();
> this.session.getBasicRemote().sendText(Integer.toString(daf));
> Thread.sleep(20);
>  }
>   } catch (Exception ex) {
> ex.printStackTrace();
>  }
> System.out.println("end");
>  }
> @OnErrorpublic void onError(Throwable e) {
>   keepingrunning = true;
>   e.printStackTrace();}}
> 
> The client is as following:
> 
> var  ws=new WebSocket("ws://localhost:8080/WebSocketTest/websocketendpoint");
> function start_webserver(){
>ws.send("ac_1");}
> 
> ws.onopen = function(evt) {
> console.log("Connection open ...");   };
> 
> ws.onmessage = function(evt) {
> console.log( "Received Message: " + evt.data);
> if(chart.series[0].data.length > 400) {
> chart.series[0].addPoint(parseFloat(evt.data), false, true, false);
> } else{
> chart.series[0].addPoint(parseFloat(evt.data), false, false, false);
> }};
> 
> ws.onclose = function(evt) {
> console.log("Connection closed.");
> ws.close();};
> 
> 
> ws.onerror = function (evt) {
>   console.log("error: ", evt);
>  };
> 
> 
> function end_webserver(){
>console.log("end the connection");
>ws.close();
>console.log("over");}
>  // the button
>  Start
>  stop
> 
> 
> Questions:
> 
> When start button clicked, the client can recieve the data to display the
> chart continously. But the stop button clicked , the onclose function both
> on client and server side did not call. It seem that onclose function is
> blocked by the onmessage function because the server keep sending data.
> Another websocket sever is tested and no problem happed. So is is the bug
> of tomcat socketserver ? Thanks.
> 
> Regards,
> Skyspeed
> 
> 
> -
> 


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

Re: CrawlerSessionManagerValve only working with default host

[Christopher Schultz]

Matt,

On 4/11/18 2:03 PM, Matt Cosentino wrote:
> I have CrawlerSessionManagerValve set up at the Engine level, but it only 
> seems to be working for the default host and not any other host. Is this 
> expected behavior? Should I put it at the host level for each host?
> 
> Here is an example of how I have it set up:
> 
> 
>   
> 
>   
>   
>   
>className="org.apache.catalina.valves.CrawlerSessionManagerValve" 
> sessionInactiveInterval="300"/>
>
> 
> Tomcat 8.5.24

I don't see anything in the code that suggests it wouldn't work when
used at the  level, but it also looks like it makes the most
sense at the  level.

Can you describe your testing and the results you got?

When you say "only [...] working for the default host", do you mean that
it works for the default host within an  (when configured at the
 level) or that it doesn't even work with a non-default 
when configured at the  level?

-chris

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

CrawlerSessionManagerValve only working with default host

[Matt Cosentino]

I have CrawlerSessionManagerValve set up at the Engine level, but it only seems 
to be working for the default host and not any other host. Is this expected 
behavior? Should I put it at the host level for each host?

Here is an example of how I have it set up:


  

  
  
  
  
   

Tomcat 8.5.24

- Matt

Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

Woonsan,

On 4/10/18 11:11 AM, Woonsan Ko wrote:
> On Tue, Apr 10, 2018 at 9:53 AM, Christopher Schultz
>  wrote:
>> All,
>>
>> I've been asked to take some static files we already have on our
>> (reverse-proxied) web servers and require authentication before allowing
>> the resources to be fetched by a client.
>>
>> One way to do that would be to physically (electronically?) move the
>> files from the web servers to the application servers, either as a part
>> of the web application itself (tricky due to licensing issues of these
>> documents) or as a separate set of files in an arbitrary place on the
>> disk e.g. using .
>>
>> Before I do that, I was thinking that maybe I could point
>>  at a (private) URL that points back to the location
>> where these files were already available. I was kind of hoping that
>> simply doing http://static/files/here/;
>> webAppMount="/static" /> or something like that.
>>
>> It looks like the existing WebResourceSet implementations are all
>> disk-based resource providers.
>>
>> It also seems like writing a simple, read-only, "non-listable"
>> implementation of an HTTPResourceSet might work for me.
>>
>> So I'm looking for opinions on what I should do, here. I might be able
>> to hack-together an HttpResourceSet, but it probably won't benefit from
>> e.g. range-requests (the files I am serving are PDFs, which often
>> benefit from being able to perform range-requests) and might be fragile.
>>
>> I could move the files to the application servers, but then I need to
>> make that a part of my app-server build process and I'd like that to
>> remain as simple as possible.
>>
>> Finally, the files cannot go into revision-control due to licensing
>> restrictions, so we basically have to keep them ... "safe" until they
>> are deployed.
>>
>> Any ideas or suggestions?
> 
> How about Reverse Proxy Servlet Filter?
> - http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html

I had thought about that, but in the end, I ended up just adding a build
target called "download-stuff" that puts the files into my web
application on each app server. Too bad 'ant' is really bad at
downloading multiple files over HTTP. :(

-chris

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

Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

André,

On 4/10/18 11:38 AM, André Warnier (tomcat) wrote:
> Hi.
> 
> On 10.04.2018 15:53, Christopher Schultz wrote:
>> All,
>>
>> I've been asked to take some static files we already have on our
>> (reverse-proxied) web servers and require authentication before allowing
>> the resources to be fetched by a client.
>>
>> One way to do that would be to physically (electronically?) move the
>> files from the web servers to the application servers, either as a part
>> of the web application itself (tricky due to licensing issues of these
>> documents) or as a separate set of files in an arbitrary place on the
>> disk e.g. using .
>>
>> Before I do that, I was thinking that maybe I could point
>>  at a (private) URL that points back to the location
>> where these files were already available. I was kind of hoping that
>> simply doing http://static/files/here/;
>> webAppMount="/static" /> or something like that.
>>
>> It looks like the existing WebResourceSet implementations are all
>> disk-based resource providers.
>>
>> It also seems like writing a simple, read-only, "non-listable"
>> implementation of an HTTPResourceSet might work for me.
>>
>> So I'm looking for opinions on what I should do, here. I might be able
>> to hack-together an HttpResourceSet, but it probably won't benefit from
>> e.g. range-requests (the files I am serving are PDFs, which often
>> benefit from being able to perform range-requests) and might be fragile.
>>
>> I could move the files to the application servers, but then I need to
>> make that a part of my app-server build process and I'd like that to
>> remain as simple as possible.
>>
>> Finally, the files cannot go into revision-control due to licensing
>> restrictions, so we basically have to keep them ... "safe" until they
>> are deployed.
>>
>> Any ideas or suggestions?
>>
> 
> I know that when you have a hammer, everything looks like a nail but why
> not set up a separate Apache httpd webserver for these things, and have
> your reverse-proxies direct the calls there for them ?

Well, my reverse-proxies are already httpd instances, so there's no need
for ANOTHER instance.

The problem is that I need Tomcat to enforce
authentication/authorization for these resources. The reverse-proxy
cannot do that, and neither can some other web server that isn't in
communication with Tomcat.

Unless there is a mod_is_user_logged_in_to_tomcat that can ping Tomcat
to see if a user is indeed logged-in and then only serve the resource if
it gets back a positive response.

> Or, use URLRewriteFilter to redirect these calls to wherever you want.
> I'm saying that because it doesn't really sound like you want to mix
> this up too much with your Java apps..

Directing the traffic isn't the problem. Enforcing authentication is.

Thanks,
-chris

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

Re: [EXTERNAL] Using CLIENT-CERT

[Christopher Schultz]

Mark and Amit,

On 4/10/18 2:21 AM, Mark Thomas wrote:
> On 9 April 2018 23:29:43 BST, Amit Pande  wrote:
>> Some more debugging here and I got some stuff working here.
>>
>> Only one question:
>>
>> It is not really clear from the documentation of "clientAuth"
>>
>> "Set to true if you want the SSL stack to require a valid certificate
>> chain from the client before accepting a connection. Set to want if you
>> want the SSL stack to request a client Certificate, but not fail if one
>> isn't presented. A false value (which is the default) will not require
>> a certificate chain unless the client requests a resource protected by
>> a security constraint that uses CLIENT-CERT authentication. See the SSL
>> HowTo for an example. That SSL HowTo also contains tips on using
>> per-user or per-session certificate-based clientAuth."
>>
>> So, if I am using a clientAuth="false" and relying on "CLIENT-CERT"
>> configuration, does that mean browsers won't prompt users to supply the
>> certificate when a protected resource is accessed?
> 
> In that scenario the browser will prompt the user for a certificate if 
> everything is correctly configured.
> 
> However, it is possible that the browser will determine that it has no 
> matching certificates and therefore decide not to display the certificate 
> prompt.

Also, sometimes browsers will "remember" your choice from a prior
interaction during the same browser session. So for example if you have
clientAuth="want" and you press "No/Cancel/[escape]/[close window]" the
browser may "remember" that you don't want to present a certificate.

-chris

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

Re: Is LDAP connection failing?

[Felix Schumacher]

Hi Luis,


Am 05.04.2018 18:50, schrieb Luis Rodríguez Fernández:

Hello Suvendu,

May I ask you to share your JNDIRealm configuration?

For me something like this works:

  
roleBase="OU=BASE_ORGANIZATION_UNIT_FOR_MY_GROUPS,OU=Workgroups,DC=cern,DC=ch"

 roleSubtree="1"
 roleName="cn"
 roleSearch="((member={0})(objectclass=group))"
/>


you are using userPattern to find users. In that case the userSubtree 
configuration

will be ignored. roleSubtree should be either "true" or "false".

Regards,
 Felix



Hope it helps,

Luis








2018-04-05 15:32 GMT+02:00 Suvendu Sekhar Mondal :


Hello Everyone,

Recently in one of our environments I am seeing following log in
Catalina.out. It seems that LDAP connection is failing. This issue is
sporadic and goes away with Tomcat recycle.

One interesting thing is "localhost:389" part. I could not find out
any configuration related to that. It could happen that I am not
looking at the correct place.

We have 200+ JVMs out there which were starting up simultaneously but
this happens for some of them sporadically. I suspect that some race
condition might be causing this failure but could not found any
evidence so far. Can someone please suggest how can I identify what is
failing? and why it is failing?

Thanks!
Suvendu

Stack trace:
2018-04-02 20:34:27,293 INFO org.apache.catalina.startup.HostConfig -
Deploying web application directory D:\xxx\webapps\ROOT
2018-04-02 20:34:33,341 SEVERE org.apache.catalina.realm.CombinedRealm
- Failed to start "org.apache.catalina.realm.JNDIRealm/1.0" realm
org.apache.catalina.LifecycleException: Failed to start component
[Realm[JNDIRealm]]
 at org.apache.catalina.util.LifecycleBase.start(
LifecycleBase.java:154)
 at org.apache.catalina.realm.CombinedRealm.startInternal(
CombinedRealm.java:201)
 at org.apache.catalina.util.LifecycleBase.start(
LifecycleBase.java:150)
 at org.apache.catalina.core.StandardContext.startInternal(
StandardContext.java:5373)
 at org.apache.catalina.util.LifecycleBase.start(
LifecycleBase.java:150)
 at org.apache.catalina.core.ContainerBase.addChildInternal(
ContainerBase.java:901)
 at org.apache.catalina.core.ContainerBase.addChild(
ContainerBase.java:877)
 at org.apache.catalina.core.StandardHost.addChild(
StandardHost.java:649)
 at org.apache.catalina.startup.HostConfig.deployDirectory(
HostConfig.java:1247)
 at org.apache.catalina.startup.HostConfig$DeployDirectory.
run(HostConfig.java:1898)
 at java.util.concurrent.Executors$RunnableAdapter.
call(Executors.java:511)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(
ThreadPoolExecutor.java:1142)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(
ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Exception opening
directory server connection
 at org.apache.catalina.realm.JNDIRealm.startInternal(
JNDIRealm.java:2191)
 at org.apache.catalina.util.LifecycleBase.start(
LifecycleBase.java:150)
 ... 14 more
Caused by: javax.naming.CommunicationException: localhost:389 [Root
exception is java.net.ConnectException: Connection refused: connect]
 at com.sun.jndi.ldap.Connection.(Connection.java:216)
 at com.sun.jndi.ldap.LdapClient.(LdapClient.java:137)
 at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
 at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
 at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319)
 at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(
LdapCtxFactory.java:70)
 at javax.naming.spi.NamingManager.getInitialContext(
NamingManager.java:684)
 at javax.naming.InitialContext.getDefaultInitCtx(
InitialContext.java:313)
 at javax.naming.InitialContext.init(InitialContext.java:244)
 at javax.naming.InitialContext.(InitialContext.java:216)
 at javax.naming.directory.InitialDirContext.(
InitialDirContext.java:101)
 at org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:2108)
 at org.apache.catalina.realm.JNDIRealm.startInternal(
JNDIRealm.java:2189)
 ... 15 more
Caused by: java.net.ConnectException: Connection refused: connect
 at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
 at java.net.AbstractPlainSocketImpl.doConnect(
AbstractPlainSocketImpl.java:350)
 at java.net.AbstractPlainSocketImpl.connectToAddress(
AbstractPlainSocketImpl.java:206)
 at java.net.AbstractPlainSocketImpl.connect(
AbstractPlainSocketImpl.java:188)
 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
 at java.net.Socket.connect(Socket.java:589)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(
NativeMethodAccessorImpl.java:62)
 at 

Re: Is LDAP connection failing?

[Felix Schumacher]

Am 05.04.2018 15:32, schrieb Suvendu Sekhar Mondal:

Hello Everyone,

Recently in one of our environments I am seeing following log in
Catalina.out. It seems that LDAP connection is failing. This issue is
sporadic and goes away with Tomcat recycle.

One interesting thing is "localhost:389" part. I could not find out
any configuration related to that. It could happen that I am not
looking at the correct place.

We have 200+ JVMs out there which were starting up simultaneously but
this happens for some of them sporadically. I suspect that some race
condition might be causing this failure but could not found any
evidence so far. Can someone please suggest how can I identify what is
failing? and why it is failing?


It would be nice to include the version of tomcat you are using.
(I am guessing it is something like 7.0.55 as the source code matches 
the line

numbers in the stacktrace)

If it is this version, then the message will be generated, when your 
ldap server
configured by connectionURL is not reachable on startup. Tomcat will try 
to
connect to the ldap server configured by alternateURL. It seems to me, 
that
you have not configured one (again guessing, as you didn't give 
configuration

details). In that case the jre is using localhost:389 and as there is no
LDAP server listening you get the exception.

Regards,
 Felix



Thanks!
Suvendu

Stack trace:
2018-04-02 20:34:27,293 INFO org.apache.catalina.startup.HostConfig -
Deploying web application directory D:\xxx\webapps\ROOT
2018-04-02 20:34:33,341 SEVERE org.apache.catalina.realm.CombinedRealm
- Failed to start "org.apache.catalina.realm.JNDIRealm/1.0" realm
org.apache.catalina.LifecycleException: Failed to start component
[Realm[JNDIRealm]]
 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)

 at
org.apache.catalina.realm.CombinedRealm.startInternal(CombinedRealm.java:201)
 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

 at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5373)
 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

 at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
 at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
 at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)

 at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247)
 at
org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1898)
 at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
 at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Exception opening
directory server connection
 at 
org.apache.catalina.realm.JNDIRealm.startInternal(JNDIRealm.java:2191)
 at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

 ... 14 more
Caused by: javax.naming.CommunicationException: localhost:389 [Root
exception is java.net.ConnectException: Connection refused: connect]
 at com.sun.jndi.ldap.Connection.(Connection.java:216)
 at com.sun.jndi.ldap.LdapClient.(LdapClient.java:137)
 at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1614)
 at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
 at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:319)
 at
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:70)
 at 
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
 at 
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)

 at javax.naming.InitialContext.init(InitialContext.java:244)
 at javax.naming.InitialContext.(InitialContext.java:216)
 at
javax.naming.directory.InitialDirContext.(InitialDirContext.java:101)
 at org.apache.catalina.realm.JNDIRealm.open(JNDIRealm.java:2108)
 at 
org.apache.catalina.realm.JNDIRealm.startInternal(JNDIRealm.java:2189)

 ... 15 more
Caused by: java.net.ConnectException: Connection refused: connect
 at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
 at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
 at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
 at
java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
 at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
 at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
 at java.net.Socket.connect(Socket.java:589)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at

Tomcat websocket server onclose failed( Tomcat 8.5)

[Funian Li]

 Dear All,

  A problem happen when tomcat websocket server was used.

   A sensor data chart with sampling freqency 50Hz is drawn. Tomcat
websocket server( Version 8.5)  is used to push the data with 20ms
interval. The server code is as following:

@ServerEndpoint("/websocketendpoint")public class WsServer {private
Session session;private boolean keepingrunning;private static
CopyOnWriteArraySet webSocketSet
 = new  CopyOnWriteArraySet();
@OnClosepublic void onClose() {
  System.out.println("Close Connection ...");
  keepingrunning = true;
  webSocketSet.remove(this);}
@OnOpenpublic void onOpen(Session session) {
   System.out.println("Open Connection ...");
   keepingrunning = true;
   this.session = session;
   webSocketSet.add(this);
 }
@OnMessagepublic void onMessage(String message, Session session) {
  System.out.println("Message from the client: " + message);
  try {
Random r = new Random();
// keep sending data
while (keepingrunning) {
int daf = r.nextInt();
this.session.getBasicRemote().sendText(Integer.toString(daf));
Thread.sleep(20);
 }
  } catch (Exception ex) {
ex.printStackTrace();
 }
System.out.println("end");
 }
@OnErrorpublic void onError(Throwable e) {
  keepingrunning = true;
  e.printStackTrace();}}

The client is as following:

var  ws=new WebSocket("ws://localhost:8080/WebSocketTest/websocketendpoint");
function start_webserver(){
   ws.send("ac_1");}

ws.onopen = function(evt) {
console.log("Connection open ...");   };

ws.onmessage = function(evt) {
console.log( "Received Message: " + evt.data);
if(chart.series[0].data.length > 400) {
chart.series[0].addPoint(parseFloat(evt.data), false, true, false);
} else{
chart.series[0].addPoint(parseFloat(evt.data), false, false, false);
}};

ws.onclose = function(evt) {
console.log("Connection closed.");
ws.close();};


ws.onerror = function (evt) {
  console.log("error: ", evt);
 };


function end_webserver(){
   console.log("end the connection");
   ws.close();
   console.log("over");}
 // the button
 Start
 stop


Questions:

When start button clicked, the client can recieve the data to display the
chart continously. But the stop button clicked , the onclose function both
on client and server side did not call. It seem that onclose function is
blocked by the onmessage function because the server keep sending data.
Another websocket sever is tested and no problem happed. So is is the bug
of tomcat socketserver ? Thanks.

Regards,
Skyspeed


-

Re: Connection closed error and certificateVerification="required"

[Richard Tearle]

On 5 April 2018 at 08:35, Richard Tearle  wrote:
>
> On 4 April 2018 at 17:58, Mark Thomas  wrote:
> > On 26/03/18 08:25, Richard Tearle wrote:
> >
> > 
> >
> > Thanks. I've got the test application and UI running but I haven't yet
> > reproduced the problem. What parameters are you calling run-test.sh with?
>
> This usually get's a failure within 10 minutes of running:
>
> ./run-test.sh 28800 5000 5000 0 0 true
>
> (I've just tried it and it failed after 4m 23s - from the previous rounds
> of testing, it failed at around the 4m 30s mark 7 times out of 10)
>
> > I'll continue to try and reproduce the issue but I think it makes sense
> > to try and generate some debug data on your system as you can reproduce it.
> >
>
> I'll get onto this, but it might not be until next week.
>
> Thanks
>
> Richard.

I've built tomcat from source using the link you provided, and rebuilt the
containers with this tomcat, and can still reproduce the issue. I've uploaded
the logs (30s before the connection closed error), to dropbox:

https://www.dropbox.com/s/qe50jbd196krtyo/logs-10-04-17.zip?dl=0

Regards

-- 

Richard

-- 
This email is sent on behalf of Northgate Public Services (UK) Limited and 
its associated companies including Rave Technologies (India) Pvt Limited 
(together "Northgate Public Services") and is strictly confidential and 
intended solely for the addressee(s). 
If you are not the intended 
recipient of this email you must: (i) not disclose, copy or distribute its 
contents to any other person nor use its contents in any way or you may be 
acting unlawfully;  (ii) contact Northgate Public Services immediately on 
+44(0)1442 768445 quoting the name of the sender and the addressee then 
delete it from your system.
Northgate Public Services has taken reasonable 
precautions to ensure that no viruses are contained in this email, but does 
not accept any responsibility once this email has been transmitted.  You 
should scan attachments (if any) for viruses.


Northgate Public Services 
(UK) Limited, registered in England and Wales under number 00968498 with a 
registered address of Peoplebuilding 2, Peoplebuilding Estate, Maylands 
Avenue, Hemel Hempstead, Hertfordshire, HP2 4NW.  Rave Technologies (India) 
Pvt Limited, registered in India under number 117068 with a registered 
address of 2nd Floor, Ballard House, Adi Marzban Marg, Ballard Estate, 
Mumbai, Maharashtra, India, 41.

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