Re: Secure Tomcat With SSL

2013-10-27 Thread Ognjen Blagojevic

Chris,

On 27.10.2013 2:47, Chris Arnold wrote:

This is both possible, only if you plan to use either BIO or NIO HTTP
connector. If you plan to use APR, connector configuration is completely
different.


Not sure what either of these are. I just need secure tomcat


Let us first determine which connector do you have configured (BIO, NIO 
or APR), because HTTPS configuration depends on connector type. Could 
you send your server.xml with comments and sensitive information removed?


Also, could you send your Tomcat startup messages? Depending on your 
configuration you can find them at the console or in file 
logs/catalina*.*. We only need to see connector initialization log 
messages, like these:


??? 19, 2013 12:01:06 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [http-apr-8080]
??? 19, 2013 12:01:06 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler [ajp-apr-8009]

In the above example, you can see that APR connector is being initialized.


If you want to find out about different connector types, you may find 
more information here:


1. 
http://people.apache.org/~markt/presentations/2009-04-01-TomcatTuning.pdf (slides 
13-20)


2. http://tomcat.apache.org/tomcat-7.0-doc/config/http.html


-Ognjen

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



Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Mark Thomas
On 26/10/2013 16:44, Johan Compagner wrote:
 I've just started looking at the javax.websocket implementation in tomcat 8
 and I have a question about how one integrates an endpoint with application
 code.  Using servlets as an analogy, web.xml allows configuration
 information to be passed to servlets when they are initialized.  Is there
 an equivalent in the javax.websocket world?  If not, are there any
 suggested practices for achieving this?

There is no direct link from web.xml since WebSockets were designed to
be implementable independently from a J2EE container.

You can provide EndpointConfig instance that contain user defined
properties.

 and i have a follow up question about this, with a servlet or a filter you
 can do: getServletContext() then you have access to the resources of the
 web application and stuff like that
 How is that possible in an websocket endpoint?

The ServerEndpointConfig will have the modifyHandshake() method called
where you have access to elements of the request and response. You need
to copy any data you need at this point.

 If i want to load in a file that is in the current webapps WEB-INF dir how
 do i do that? How do i get an url or inputstream (getResource() call) to
 that file?

Calls via the class loader will continue to work.

Mark


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



Possible serious bug in Tomcat 7's websocket UpgradeUtil when handling concurrent connections that use a custom ServerEndpointConfig.Configurator

2013-10-27 Thread Bob DeRemer
It appears that there is a problem in Tomcat's static UpgradeUtil.doUpgrade 
logic when handling concurrent connection/upgrade requests that rely on a 
custom ServerEndpointConfig.Configurator.modifyHandshake to grab 
[per-upgrade-request] client header values and inject them into the wsSession 
that is being created.

Specifically, the static doUpgrade does not appear to make a copy of the 
ServerEndpointConfig before calling modifyHandshake.   As a result, any 
per-connection headers the Configurator may grab and put in the 
ServerEndpointConfig.UserProperties map will be overwritten by the last upgrade 
request that occurs before the upgrade logic creates the new wsSession in the 
WsHttpUpgradeHandler.init call.

I am able to replicate this very easily by using the following server 
configurator code.  By making concurrent websocket connect requests that place 
a unique client-id in the upgrade request headers, then grabbing that 
client-id property using the code below, ALL websocket sessions that get 
created will have the last client-id header value that came in concurrently.

public class Jsr356ServerConfigurator extends ServerEndpointConfig.Configurator
{
@Override
public void modifyHandshake(ServerEndpointConfig config, HandshakeRequest 
request, HandshakeResponse response)
{
  // get the request headers - looking for security claims and 
endpoint ID
  // claims will be checked in the OnOpen call and the connection 
closed if AUTH check fails
  MapString, ListString headers = request.getHeaders();

  String id = headers.get(client-id).get(0);

  config.getUserProperties().put(client-id, id);
}
}

@ServerEndpoint(...)
Public class MyServer
{
@OnOpen
public void onOpen(Session session)
{
  String id = (String) session.getUserProperties().get(client-id);
  _logger.warn(client ID: {}, id);
}
}


Based on chapter 3 of the JSR-356 API document, the actual websocket handshake 
process defined in the websocket spec,  and the online description of the 
process in this stackoverflow link 
(http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint/17994303#17994303),
 it appears that we should be able to pass per-client information in the 
upgrade headers and we should be able to get them into the endpoint INSTANCE's 
Session user properties.

If this is a bug, please confirm and I will create a bugzilla entry, as it is 
very important that that we be able to do what I've described above.

If this is not a bug, can someone please describe how to obtain per-client 
instance data during the handshake/onOpen process?


Thanks,
Bob

http://www.thingworx.comhttp://www.thingworx.com/
Skype: bob.deremer.thingworx



Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Johan Compagner
  and i have a follow up question about this, with a servlet or a filter
 you
  can do: getServletContext() then you have access to the resources of the
  web application and stuff like that
  How is that possible in an websocket endpoint?

 The ServerEndpointConfig will have the modifyHandshake() method called
 where you have access to elements of the request and response. You need
 to copy any data you need at this point.


i was not talking about (http)request or response objects.
But purely the ServletContext to access stuff of the web app itself.


  If i want to load in a file that is in the current webapps WEB-INF dir
 how
  do i do that? How do i get an url or inputstream (getResource() call) to
  that file?

 Calls via the class loader will continue to work.


It's not a resource in the WEB-INF/classes or a resource in a jar file
I am talking about a normal resource anywhere in a war file itself (thats
not in jars/classes)
So for example i just want to get the content of the index.html in the root
of the myapp.war
Or i want a special properties file that i have in the
myapp.war/WEB-INF/my.properties


in a filter or servlet:

getServletContext().getResource(WEB-INF/my.properties);

what is the line of code in a web socket endpoint to do the same?
It seems that it is impossible to get the context of the webapp the socket
is in..

johan


Re: [ANN] Apache Tomcat 7.0.47 released

2013-10-27 Thread Johan Compagner
On 26 October 2013 21:59, Violeta Georgieva violet...@apache.org wrote:

 This release contains a number of bug fixes and improvements compared to
 version 7.0.42. The notable changes include:
 - Back-port the JSR-356 Java WebSocket 1.0 implementation from Apache
   Tomcat 8.
 - Deprecate the Apache Tomcat proprietary WebSocket API in favour of the
   new JSR-356 implementation.
 - Add a drawing board example to the WebSocket examples.



i guess this page should now be updated:

http://tomcat.apache.org/whichversion.html





-- 
Johan Compagner
Servoy


Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Mark Thomas
On 27/10/2013 12:36, Johan Compagner wrote:
 and i have a follow up question about this, with a servlet or a filter
 you
 can do: getServletContext() then you have access to the resources of the
 web application and stuff like that
 How is that possible in an websocket endpoint?

 The ServerEndpointConfig will have the modifyHandshake() method called
 where you have access to elements of the request and response. You need
 to copy any data you need at this point.

 
 i was not talking about (http)request or response objects.
 But purely the ServletContext to access stuff of the web app itself.

You'd have to put the ServletContext into the EndpointConfig.

 If i want to load in a file that is in the current webapps WEB-INF dir
 how
 do i do that? How do i get an url or inputstream (getResource() call) to
 that file?

 Calls via the class loader will continue to work.


 It's not a resource in the WEB-INF/classes or a resource in a jar file
 I am talking about a normal resource anywhere in a war file itself (thats
 not in jars/classes)
 So for example i just want to get the content of the index.html in the root
 of the myapp.war
 Or i want a special properties file that i have in the
 myapp.war/WEB-INF/my.properties
 
 
 in a filter or servlet:
 
 getServletContext().getResource(WEB-INF/my.properties);
 
 what is the line of code in a web socket endpoint to do the same?
 It seems that it is impossible to get the context of the webapp the socket
 is in..

It isn't exposed via the API because WebSockets were designed to
be implementable independently from a J2EE container. You can do it via
the EndpointConfig but you have to do your own plumbing.

Mark


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



Re: Apache 7, Logrotate

2013-10-27 Thread Rainer Jung
On 25.10.2013 11:54, Konstantin Kolinko wrote:
 2013/10/25 Web2 Solutions m...@web2-solutions.com:
 Hallo All,

 I've installed tomcat 7.0.42 and due heavy use my catalina.out and
 localhost_access-jjj-mm-dd.txt grows quit big.

 I've successfully configured logrotate to rotate both files. I've removed
 the date from the access log.
 So Tomcat now writes without rotating into localhost_access.txt

 Logrotate now create a new file (localhost_access-dd-mm-dd.txt) and makes
 localhost_access.txt empty.
 But tomcat now writes into the new localhost_access-dd-mm-dd.txt instead of
 the configured file (localhost_access.txt).
 
 FYI:
 You can configure the filename pattern so that it rotates more frequently,
 e.g. every hour or every ten minutes.
 
 What do I have todo so that tomcat continues to write into
 localhost_access.txt  even after rotating?
 
 Renaming the file is futile, because Tomcat (for access logs) or the
 shell (for catalina.out)
 has the file open and continues to write to it, regardless of the file name.
 
 You can use copytruncate option of logrotate.
 
 FYI: catalina.out is not a proper log file, but a redirection of
 stdout (as managed in catalina.sh script that launches Tomcat java
 process). If a system is configured properly, this file is usually
 empty.

Only for the access log: there's a property checkExists=true, that
will close the file and reopen it if the access log valve detects the
file has been moved/renamed. That option could be more expensive though
then just using an appropriate value for fileDateFormat.

Regards,

Rainer


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



Re: [ANN] Apache Tomcat 7.0.47 released

2013-10-27 Thread Violeta Georgieva
2013/10/27 Johan Compagner jcompag...@servoy.com

 On 26 October 2013 21:59, Violeta Georgieva violet...@apache.org wrote:

  This release contains a number of bug fixes and improvements compared to
  version 7.0.42. The notable changes include:
  - Back-port the JSR-356 Java WebSocket 1.0 implementation from Apache
Tomcat 8.
  - Deprecate the Apache Tomcat proprietary WebSocket API in favour of the
new JSR-356 implementation.
  - Add a drawing board example to the WebSocket examples.
 


 i guess this page should now be updated:

 http://tomcat.apache.org/whichversion.html

Thanks for pointing that.
It should be fixed now.

 --
 Johan Compagner
 Servoy


Regards
Violeta


Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Neil Martin
Thanks for the replies Mark.

It does seem to me that most developers using websockets under tomcat are going 
to want that integration with the J2EE container.  Maybe I'm wrong, but it 
seems like the plumbing to make the servlet context available to the 
EndpoingConfig will be messy because the websockets framework has been designed 
to be divorced from its environment.

From this perspective, the tomcat 7 websockets implementation seems easier to 
work with; at least for developers who are looking to use websocket endpoints 
as a replacement for servlets.  Does this make sense?

Neil

Sent from my iPad

 On Oct 27, 2013, at 8:04, Mark Thomas ma...@apache.org wrote:
 
 On 27/10/2013 12:36, Johan Compagner wrote:
 and i have a follow up question about this, with a servlet or a filter
 you
 can do: getServletContext() then you have access to the resources of the
 web application and stuff like that
 How is that possible in an websocket endpoint?
 
 The ServerEndpointConfig will have the modifyHandshake() method called
 where you have access to elements of the request and response. You need
 to copy any data you need at this point.
 
 i was not talking about (http)request or response objects.
 But purely the ServletContext to access stuff of the web app itself.
 
 You'd have to put the ServletContext into the EndpointConfig.
 
 If i want to load in a file that is in the current webapps WEB-INF dir
 how
 do i do that? How do i get an url or inputstream (getResource() call) to
 that file?
 
 Calls via the class loader will continue to work.
 It's not a resource in the WEB-INF/classes or a resource in a jar file
 I am talking about a normal resource anywhere in a war file itself (thats
 not in jars/classes)
 So for example i just want to get the content of the index.html in the root
 of the myapp.war
 Or i want a special properties file that i have in the
 myapp.war/WEB-INF/my.properties
 
 
 in a filter or servlet:
 
 getServletContext().getResource(WEB-INF/my.properties);
 
 what is the line of code in a web socket endpoint to do the same?
 It seems that it is impossible to get the context of the webapp the socket
 is in..
 
 It isn't exposed via the API because WebSockets were designed to
 be implementable independently from a J2EE container. You can do it via
 the EndpointConfig but you have to do your own plumbing.
 
 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



Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Niki Dokovski
On Sun, Oct 27, 2013 at 4:46 PM, Neil Martin nsm...@gmail.com wrote:

 Thanks for the replies Mark.

 It does seem to me that most developers using websockets under tomcat are
 going to want that integration with the J2EE container.  Maybe I'm wrong,
 but it seems like the plumbing to make the servlet context available to the
 EndpoingConfig will be messy because the websockets framework has been
 designed to be divorced from its environment.

 From this perspective, the tomcat 7 websockets implementation seems easier
 to work with; at least for developers who are looking to use websocket
 endpoints as a replacement for servlets.  Does this make sense?


Perhaps, such request can be posted on EG mail list [1] or JIRA  issue
tracker [2]

[1] jsr356-expe...@websocket-spec.java.net
[2] http://java.net/jira/browse/WEBSOCKET_SPEC



 Neil

 Sent from my iPad

  On Oct 27, 2013, at 8:04, Mark Thomas ma...@apache.org wrote:
 
  On 27/10/2013 12:36, Johan Compagner wrote:
  and i have a follow up question about this, with a servlet or a filter
  you
  can do: getServletContext() then you have access to the resources of
 the
  web application and stuff like that
  How is that possible in an websocket endpoint?
 
  The ServerEndpointConfig will have the modifyHandshake() method called
  where you have access to elements of the request and response. You need
  to copy any data you need at this point.
 
  i was not talking about (http)request or response objects.
  But purely the ServletContext to access stuff of the web app itself.
 
  You'd have to put the ServletContext into the EndpointConfig.
 
  If i want to load in a file that is in the current webapps WEB-INF dir
  how
  do i do that? How do i get an url or inputstream (getResource() call)
 to
  that file?
 
  Calls via the class loader will continue to work.
  It's not a resource in the WEB-INF/classes or a resource in a jar file
  I am talking about a normal resource anywhere in a war file itself
 (thats
  not in jars/classes)
  So for example i just want to get the content of the index.html in the
 root
  of the myapp.war
  Or i want a special properties file that i have in the
  myapp.war/WEB-INF/my.properties
 
 
  in a filter or servlet:
 
  getServletContext().getResource(WEB-INF/my.properties);
 
  what is the line of code in a web socket endpoint to do the same?
  It seems that it is impossible to get the context of the webapp the
 socket
  is in..
 
  It isn't exposed via the API because WebSockets were designed to
  be implementable independently from a J2EE container. You can do it via
  the EndpointConfig but you have to do your own plumbing.
 
  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




Re: Tomcat 8 Websockets configuration

2013-10-27 Thread Johan Compagner
On 27 October 2013 16:09, Niki Dokovski nick...@gmail.com wrote:

 On Sun, Oct 27, 2013 at 4:46 PM, Neil Martin nsm...@gmail.com wrote:

  Thanks for the replies Mark.
 
  It does seem to me that most developers using websockets under tomcat are
  going to want that integration with the J2EE container.  Maybe I'm wrong,
  but it seems like the plumbing to make the servlet context available to
 the
  EndpoingConfig will be messy because the websockets framework has been
  designed to be divorced from its environment.
 
  From this perspective, the tomcat 7 websockets implementation seems
 easier
  to work with; at least for developers who are looking to use websocket
  endpoints as a replacement for servlets.  Does this make sense?
 

 Perhaps, such request can be posted on EG mail list [1] or JIRA  issue
 tracker [2]

 [1] jsr356-expe...@websocket-spec.java.net
 [2] http://java.net/jira/browse/WEBSOCKET_SPEC



I guess what would be nice is that an end point just needs to implement 1
interface IContextAware that has one method:
setServletContext(ServletContext)
that is then called by the container at the moment the endpoint does
implement that interface..

 Now i guess the only way to get it through the http session that is gotten
through the ServerEndpoint:
http://stackoverflow.com/questions/17936440/accessing-httpsession-from-httpservletrequest-in-a-web-socket-socketendpoint

But is there always directly a HttpSession? Because if that is not the case
(i only hit the server with the ws:// url) then i can't get to the context
at all.

johan


Re: [ANN] Apache Tomcat 7.0.47 released

2013-10-27 Thread Johan Compagner


   i guess this page should now be updated:
 
  http://tomcat.apache.org/whichversion.html

 Thanks for pointing that.
 It should be fixed now.



only that the minimum version of Tomcat 7 is now not always java 6 ;)


Question about websockets origin and remote addresses

2013-10-27 Thread Marcelo v
Hello My name is Marcelo, i have a little web site and i am using apache
tomcat 8.0.0-RC5 and making use of JSR-356 websocket api ... (i followed
the ChatAnnotation example) ...
I almost finished the development when i found 2 problems ...

1) Is it possible to get the remote ip of the client on @OnOpen method ???
i was not able to find this answer

2) Is it possible to know the origin of connections ??? i mean the domain
of the page the connection was made 

The first question is because i have a list of banned addresses already ...
The second is because i need a minimal check on that, because it is not
allowed the connections to be made from anywhere ...

It is the first question i make here ... probably there is not enough
information .. please let me know ...

Thank you


Fwd: Tomcat 7.0.47 Websocket + JNDI problems

2013-10-27 Thread Francesco Bassi
Hello everybody.

I just downloaded 7.0.47 and updated one web application that I developed
in order to use the new standard JSR 356 websocket implementation.

With this new implementation, I noticed that during the processing of
incoming websocket events, it's not possible to access the JNDI resources.

ie:

Context initCtx = new InitialContext();
Context c = (Context) initCtx.lookup(java:comp/env);

gives

javax.naming.NameNotFoundException: Name [comp/env] is not bound in this
Context. Unable to find [comp].

I'm using a custom ServerEndpointConfig.Configurator.

Everything used to work properly with the old custom tomcat implementation.

Is it an expected behaviour?

thanks,

--fb


Re: Tomcat 7.0.47 Websocket + JNDI problems

2013-10-27 Thread Konstantin Kolinko
2013/10/28 Francesco Bassi fvba...@gmail.com:
 Hello everybody.

 I just downloaded 7.0.47 and updated one web application that I developed
 in order to use the new standard JSR 356 websocket implementation.

 With this new implementation, I noticed that during the processing of
 incoming websocket events, it's not possible to access the JNDI resources.

 ie:

 Context initCtx = new InitialContext();
 Context c = (Context) initCtx.lookup(java:comp/env);

 gives

 javax.naming.NameNotFoundException: Name [comp/env] is not bound in this
 Context. Unable to find [comp].

 I'm using a custom ServerEndpointConfig.Configurator.

 Everything used to work properly with the old custom tomcat implementation.

 Is it an expected behaviour?


I think it means that  the thread where you process those events does
not have its Thread.getContextClassLoader() (aka TCCL) configured and
thus JNDI does not know to what web application this thread belongs.

Can you provide the stack trace of the place where you access JNDI
and check what is the value of
Thread.currentThread().getContextClassLoader() there?

If the class loader is not a o.a.c.loader.WebappClassLoader one, I
think it is OK to create a bugzilla issue.


Best regards,
Konstantin Kolinko

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