How to make database connection pool show in JMX

[Pawel Veselov]

Hello.

I'd like to get some JMX stats out of the JDBC connection pools. But
they don't seem to register
in JMX, even though they are based on ConnectionPoolMBean.

I do create the pools programmatically, by binding the factory into
the JNDI, the creation snippet is
copied below. When I search for JMX objects, I don't see anything that
looks like the pool info,
but I'm also not sure what the object name is supposed to be. I expect
it to be in "Catalina"
domain, though some of the code I saw suggests it may be in
"tomcat.jdbc" domain instead... I
don't have any "tomcat." domains at all.

Any clues are appreciated.

--
Properties p = new Properties();

p.setProperty("type", "javax.sql.Datasource");
p.setProperty("defaultAutoCommit", "false");
// <...> set some other properties here
// enable JMX
p.setProperty("jmxEnabled", String.valueOf(Boolean.TRUE));
// JNDI of the actual data source
p.setProperty("dataSourceJNDI", pooledDSName);
Class dsfClass =
Class.forName("org.apache.tomcat.jdbc.pool.DataSourceFactory");
Object dsf = dsfClass.newInstance();
Method m = dsfClass.getDeclaredMethod("createDataSource",
Properties.class);
return m.invoke(dsf, p);
// the result is bound into JNDI
--

Thank you!

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

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Robert J. Carr]

On Tue, Jan 23, 2018 at 9:54 AM, Konstantin Kolinko 
wrote:

> 2018-01-22 11:25 GMT+03:00 Robert J. Carr :
> > Hi Mark, everyone-
> >
> > I've constructed a sample app of ~5 files.  The code is bundled in the
> jar
> > file in the WEB-INF/lib directory.  Here's a public url for the
> application
> > (test.war; 8K):
> >
> >
> > https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HHfr
> SS4/view?usp=sharing
> >
>
> Thank you for the sample application! It is easy to reproduce the issue.
>
> I filed it into Bugzilla:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62036
>
> I went on to upload your test.war there (I fixed some typos in web.xml
> and repacked). I hope that you do not mind.
>
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Hi Konstantin-

Thanks for looking into this, and yes, it's fine to share the example
application.

It looks like you've already done some research.  I'll follow the defect
ticket and see what happens.  I was hoping there was just some
configuration I was missing, so I'll still hold out for that.

Thanks again for the time, and a special thanks for confirming I'm not
crazy! :)

Robert

[ANN] Apache Tomcat 8.5.27 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 8.5.27.

Tomcat 8.x users should normally be using 8.5.x releases in preference
to 8.0.x releases.

Apache Tomcat 8 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and Java Authentication Service Provider Interface for
Containers technologies.

Apache Tomcat 8.5.x is intended to replace 8.0.x and includes new
features pulled forward from the 9.0.x branch. The notable changes since
8.5.24 include:


- Add support for GZIP compression with HTTP/2

- Expand the TLS functionality exposed via the Manager application

- Return a simple, plain text error message if a client attempts to make
  a plain text HTTP connection to a TLS enabled NIO or NIO2 Connector.

- Add a new system property
  (org.apache.jasper.runtime.BodyContentImpl.BUFFER_SIZE) to control the
  size of the buffer used by Jasper when buffering tag bodies.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-80.cgi

Migration guides from Apache Tomcat 7.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team


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

Re: Can't Get SSL to Work in 8.5

[Coty Sutherland]

On Tue, Jan 23, 2018 at 2:16 PM, Kenneth Taylor
 wrote:
> Coty,
>
> Thank you very much. That worked.  The only thing is its not redirecting to 
> SSL if you hit the regular URL.  Are we missing something?

Do you have a CONFIDENTIAL transport guarantee defined for the
applications that you want to redirect? The redirectPort doesn't work
exactly like most people think it does (e.g. it doesn't redirect all
traffic to the port), it redirects traffic for applications with a
transport guarantee that requires SSL. From the http configuration doc
(https://tomcat.apache.org/tomcat-8.5-doc/config/http.html) for
redirectPort: "If this Connector is supporting non-SSL requests, and a
request is received for which a matching 
requires SSL transport, Catalina will automatically redirect the
request to the port number specified here."

You can place a confidential transport guarantee in your application's
web.xml such as:


  
CONFIDENTIAL
  


I guess if you wanted to redirect EVERYTHING from 8080 to 8443 you
could add a constraint in the global web.xml:


  
Everything
/*
  
  
CONFIDENTIAL
  


but...I'm not sure if that would play nicely with everything or cause
problems :)

HTH

>  connectionTimeout="2"
> port="8080"
> protocol="HTTP/1.1"
> redirectPort="8443"
> scheme="http"
> secure="false"/>
>
>  SSLEnabled="true"
> maxThreads="20"
> port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> sslImplementation="org.apache.tomcat.util.net.jsse.JSSEImplemntation"
> scheme="https"
> secure="true">
>  name="_default_"
> clientAuth="false"
> sslProtocol="TLS"
> protocols="TLSv1.2"
> sessionCacheSize="5"
> sessionTimeout="960">
>  certificateKeyAlias="dmb-kenneth"
> certificateKeystoreFile="conf/localhost-rsa.jks"
> certificateKeystorePassword="=NR5^vtuW_/?"
> certificateVerification="optionalNoCA"
> type="RSA"/>
> 
> 
>
> Thanks
> Ken
>
> -Original Message-
> From: Coty Sutherland [mailto:csuth...@apache.org]
> Sent: Monday, January 22, 2018 2:24 PM
> To: Tomcat Users List 
> Subject: Re: Can't Get SSL to Work in 8.5
>
> On Mon, Jan 22, 2018 at 2:23 PM, Kenneth Taylor 
>  wrote:
>> We are trying to get SSL to work in 8.5 and have been unsuccessful.  We 
>> followed all the instructions in the Tomcat documentation and what help is 
>> available on the net but have been unable to get TC to startup with an SSL 
>> Connector configured.
>>
>> Here is our Connector configuration:
>>
>> > scheme="http" redirectPort="8443" secure="false"/>
>>
>> > SSLEnabled="true"
>> clientAuth="false"
>> maxThreads="20"
>> port="8443"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> sslImplementation="org.apache.tomcat.util.net.jsse.JSSEImplemntation"
>> scheme="https"
>> secure="true"
>> sslProtocol="TLS">
>
> Remove  `clientAuth="false"` and `sslProtocol="TLS"` from the Connector 
> element and place them inside the SSLHostConfig element below. These two 
> attributes are now SSLHostConfig attributes (even though they are allowed in 
> the Connector because tomcat translates them to a default SSLHostConfig 
> object initialized with those values).
> It's also noteworthy that you're using the default values for clientAuth and 
> sslProtocol, so they aren't necessary.
>
>> > hostName="localhost"
>
> You need an SSLHostConfig that's named _default_ for this to work (which is 
> the default name) so remove hostName="localhost" too and this should work :)
>
> I'm going to file a BZ and see if others are interested in catching this NPE 
> and doing something more useful with it. I'm also going to file an 
> enhancement to remove the requirement to have a _default_ SSLHostConfig, if 
> possible.
>
>> protocols="TLSv1.2"
>> sessionCacheSize="15"
>> sessionTimeout="960">
>>  >  certificateKeyAlias="localhost"
>>  certificateKeystoreFile="conf/localhost-rsa.jks"
>>  certificateKeystorePassword="=NR5^vtuW_/?"
>>  certificateVerification="optionalNoCA"
>>  type="RSA"/>
>> 
>> 
>>
>> Here is the error we get:
>>
>> Jan 19, 2018 2:24:07 PM org.apache.catalina.core.StandardService
>> initInternal
>> SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
>> org.apache.catalina.LifecycleException: Failed to initialize component
>> [Connector[HTTP/1.1-8443]] at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
>> at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.
>> java:549) at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja
>> va:875) at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
>> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
>> at 

RE: Can't Get SSL to Work in 8.5

[Kenneth Taylor]

Coty,

Thank you very much. That worked.  The only thing is its not redirecting to SSL 
if you hit the regular URL.  Are we missing something?









Thanks
Ken

-Original Message-
From: Coty Sutherland [mailto:csuth...@apache.org]
Sent: Monday, January 22, 2018 2:24 PM
To: Tomcat Users List 
Subject: Re: Can't Get SSL to Work in 8.5

On Mon, Jan 22, 2018 at 2:23 PM, Kenneth Taylor 
 wrote:
> We are trying to get SSL to work in 8.5 and have been unsuccessful.  We 
> followed all the instructions in the Tomcat documentation and what help is 
> available on the net but have been unable to get TC to startup with an SSL 
> Connector configured.
>
> Here is our Connector configuration:
>
>  scheme="http" redirectPort="8443" secure="false"/>
>
>  SSLEnabled="true"
> clientAuth="false"
> maxThreads="20"
> port="8443"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> sslImplementation="org.apache.tomcat.util.net.jsse.JSSEImplemntation"
> scheme="https"
> secure="true"
> sslProtocol="TLS">

Remove  `clientAuth="false"` and `sslProtocol="TLS"` from the Connector element 
and place them inside the SSLHostConfig element below. These two attributes are 
now SSLHostConfig attributes (even though they are allowed in the Connector 
because tomcat translates them to a default SSLHostConfig object initialized 
with those values).
It's also noteworthy that you're using the default values for clientAuth and 
sslProtocol, so they aren't necessary.

>  hostName="localhost"

You need an SSLHostConfig that's named _default_ for this to work (which is the 
default name) so remove hostName="localhost" too and this should work :)

I'm going to file a BZ and see if others are interested in catching this NPE 
and doing something more useful with it. I'm also going to file an enhancement 
to remove the requirement to have a _default_ SSLHostConfig, if possible.

> protocols="TLSv1.2"
> sessionCacheSize="15"
> sessionTimeout="960">
>certificateKeyAlias="localhost"
>  certificateKeystoreFile="conf/localhost-rsa.jks"
>  certificateKeystorePassword="=NR5^vtuW_/?"
>  certificateVerification="optionalNoCA"
>  type="RSA"/>
> 
> 
>
> Here is the error we get:
>
> Jan 19, 2018 2:24:07 PM org.apache.catalina.core.StandardService
> initInternal
> SEVERE: Failed to initialize connector [Connector[HTTP/1.1-8443]]
> org.apache.catalina.LifecycleException: Failed to initialize component
> [Connector[HTTP/1.1-8443]] at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:112)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.
> java:549) at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.ja
> va:875) at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:607)
> at org.apache.catalina.startup.Catalina.load(Catalina.java:630)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498)
> at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:311)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:494)
> Caused by: org.apache.catalina.LifecycleException: Protocol handler
> initialization failed at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:99
> 9) at
> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:107)
> ... 12 more
> Caused by: java.lang.IllegalArgumentException:
> java.lang.NullPointerException at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
> actJsseEndpoint.java:114) at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(Abstract
> JsseEndpoint.java:85) at
> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:225)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java
> :970) at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpo
> int.java:244) at
> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:613)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Pro
> tocol.java:66) at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:99
> 7)
> ... 13 more
> Caused by: java.lang.NullPointerException at
> java.io.FileInputStream.(FileInputStream.java:130)
> at java.io.FileInputStream.(FileInputStream.java:93)
> at java.io.FileReader.(FileReader.java:58)
> at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:74)
> at
> org.apache.tomcat.util.net.jsse.JSSEUtil.getKeyManagers(JSSEUtil.java:
> 193) 

Re: roles stripped when using login() in tomcat 8.5 but not 8.0

[Konstantin Kolinko]

2018-01-22 11:25 GMT+03:00 Robert J. Carr :
> Hi Mark, everyone-
>
> I've constructed a sample app of ~5 files.  The code is bundled in the jar
> file in the WEB-INF/lib directory.  Here's a public url for the application
> (test.war; 8K):
>
>
> https://drive.google.com/file/d/1mZRXrm90F4WN3mizqoqrWYmQ1HHfrSS4/view?usp=sharing
>

Thank you for the sample application! It is easy to reproduce the issue.

I filed it into Bugzilla:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62036

I went on to upload your test.war there (I fixed some typos in web.xml
and repacked). I hope that you do not mind.


Best regards,
Konstantin Kolinko

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

Fwd: logging on shutdown

[Greg Huber]

The log4j2 Log4jServletContextListener contextDestroyed seems to be
shutting down first, before my stuff, hence no logging.  Will look into
this, more a log4j2 issue.

Cheers Greg

-- Forwarded message --

Subject: logging on shutdown
To: Tomcat Users List 


Hello,

I tried the latest version 9.0.4,  one thing I have noticed that it does
not log any output when I shut down the server.  Also Rechecking version
8.5.24 and also now does not log any output.

The server is shutting down correctly as its calling my context finalise
listener contextDestroyed() and cleaning up search lock files etc.

My logging is working as I can see the startup messages. I have a basic
install with no changes to conf dir files.

Any ideas?

Cheers Greg

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 1/23/18 9:04 AM, Mark H. Wood wrote:
> Well, there are several layers of problems here, with different
> ways of addressing them.
> 
> Command lines are available using 'ps', so any secrets written on
> the command line are visible to anyone able to get a session on
> that host, for the duration of the command.  There's no way around
> this that I know of.
> 
> Process environment variables may also be visible to all and
> sundry, so moving secrets from the command line to the environment
> just makes slightly more work for the snooper.  Removing them from
> the shell's environment after use may not help, because typically
> the environment is cloned when a process is forked, so the service
> process will have copies that aren't removed.

I would argue that environment variables are more secure than system
properties (when passed on the command-line) because accessing a
process's environment variables usually requires some appropriate
level of access, whereas 'ps' is open to everyone, of course.

But of course there are even better solutions...

> The people who wrote the Servlet spec. seem to me to have been 
> thinking that the context for an instance of an app. would be 
> generated by an installer program or by the container's management 
> tools.  You could write a simple script to generate a context 
> declaration which is customized for a specific instance.  Unlike
> the command line or the process environment, files (such as a 
> free-standing context declaration) can be protected by the 
> filesystem.  This is your best noninteractive bet.

+1

> As mentioned by another, the way to limit availability of 
> machine-readable secrets to the greatest extent is to require an 
> operator to type them in at startup.  However, you'll need to
> consider the consequences of this if your container is
> automatically started at system startup -- you may need a way to
> let an individual context's startup wait for an operator to appear
> without hanging the whole system startup procedure.  (Automatic
> startup is another common thing that the spec. authors seem to have
> believed to be Somebody Else's Problem.)

I have a few machines with encrypted filesystems on them and, because
I understand that having the fs password in a startup script is
tantamount to not having an encrypted filesystem at all, I have to
enter the password for the crypto fs every time the machine is
restarted. This happens maybe once per quarter (3 mos... more often
when kernel patches are coming out several times per day like
recently) and it's a giant pain in my neck. Unless it's absolutely
required, don't put a human process in where an automated process will d
o.

> For completeness:  in your own code, you'll also wish to ensure
> that you obliterate (not just discard) secrets as soon as you have
> no further need for them.  That means that, within the JVM, they
> should only ever exist in mutable objects (not String, for
> example).

I disagree. There is almost no way to scrub memory in a JVM process.
Hell, it's almost impossible to scrub memory even in a native process
due to the way that the OS virtualizes memory regions. The OS can
write a page to disk without you even knowing about it, and not your
secret is on the disk. Yes, there are ways to tell the OS not to swap
that memory, but at some point you end up writing more scrubbing code
than anything else.

Take the JVM example. Let's say that you have a secret that is only
required for a short amount of time. You read it in from somewhere and
put it into a char[] object. That char[] object is mutable and sure,
you can write 0x00 to all of the char values before you discard the
object and allow it to be collected by the GC. But before you have the
chance to scrub it, the memory manager can relocate the char[] object
to another place within the current (or even a different) heap region.
Without native code, there is no way to prevent that from happening.
The GC can even run during your scrubbing-operation and you end up
with a copy of a half-scrubbed secret sitting around in an
unpredictable memory location.

Let's say you decide it's super-important to scrub that memory and you
understand that you have to pin the object in memory to scrub it
properly. So you write a native method to pin/scrub/unpin the object.
Well, what was the history of that object *before* you tried to pin it?

Okay, now we have to go 100% native and pin our char[] object, read
the data from wherever, use it for authentication/signing/whatever,
then scrub and unpin the object. Oh, and don't forget to tell the OS
not to swap-out that page of memory in the meantime.

Bullet-proof, right?

Sorry, no. In the process of using that secret to
authentication/sign/whatever, you may find that the
authentication/signing/whatevering library makes a copy of the secret.
Say... for easy-access. Is that library scrubbing the memory? Not
sure. Let's say that library 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

Thanks for the feedback. -Al

On Tue, Jan 23, 2018 at 11:05 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Algirdas,
>
> On 1/23/18 6:11 AM, Algirdas Veitas wrote:
> > Thanks for the quick reply George!
> >
> > We could, but the data is still available, in this case a file,
> > versus in the output of "ps -ef | grep java".  We can obviously
> > encrypt the sensitive information.
>
> Use sane file permissions?
>
> While you are at it, why not just put the db username and password
> into your application's META-INF/context.xml file where they belong?
>
> > One idea, in order to support injecting Environment Variables would
> > be to support a syntax of
> >
> > ${env.DB_USER}
> >
> > where if the subsitution property starts with "env", then the
> > variable could be retrieve by System.getEnv(...) otherwise
> > System.getProperty(...).
>
> We *could* do that, but why?
>
> Is there a reason to think that file permissions are easier to break
> than, well, file permissions (think /proc/[pid]/environ)?
>
> - -chris
>
> > On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev
> >  wrote:
> >
> >> Can you use catalina.properties? From the docs [1]
> >>
> >> " All system properties are available including those set using
> >> the -D syntax, those automatically made available by the JVM and
> >> those configured in the $CATALINA_BASE/conf/catalina.properties
> >> file."
> >>
> >> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
> >>
> >>
> >> -Original Message- From: Algirdas Veitas
> >> [mailto:apvei...@gmail.com] Sent: Monday, January 22, 2018 4:02
> >> PM To: users@tomcat.apache.org Subject: Using Environment
> >> variables instead of Java -D properties for context.xml
> >> substitution
> >>
> >> Hi,
> >>
> >> We have a context.xml under $TOMCAT_HOME/conf that looks like
> >> this:
> >>
> >>  >> type="javax.sql.DataSource" username="${DB_USERNAME}"
> >> password="${DB_PASSWORD}"
> >> driverClassName="oracle.jdbc.OracleDriver"
> >> validationQuery="select 1 from dual" testOnBorrow="true"
> >> url="${DB_URL}" />
> >>
> >> if we do something like this in setenv.sh, the substitution works
> >> great
> >>
> >> export DB_USERNAME=xyz export DB_PASSWORD=vvv
> >>
> >> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME" export
> >> JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
> >>
> >> However, if on a linux box, if someone did a "ps -ef | grep
> >> java", they would be able to see the actual values of these
> >> parameters.
> >>
> >> theuser 127734  1  0 Jan19 ?00:04:39
> >> /opt/java/bin/java
> >> -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
> >> tomcat/apache-tomcat/conf/logging.properties
> >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> >>
> >>
> - -DDB_USERNAME=xyz
> >> -DDB_PASSWORD=vvv
> >>
> >> Which our operations team does not want
> >>
> >> Is there any syntax that Tomcat can recognize to substitute true
> >> environment variables (i.e. export DB_USERNAME=xyz) as opposed to
> >> Java properties injected into the JVM by -D (i.e. export
> >> DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any
> >> documentation on it, but thought would ask.
> >>
> >> Thanks in advance, Al
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD
> AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma
> ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN
> GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l
> jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO
> zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI
> 1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY
> TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH
> crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM
> NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK
> DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ
> a4mP2K3f7yHoWBxCG3zhxjli56o=
> =MG1G
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Algirdas,

On 1/23/18 6:11 AM, Algirdas Veitas wrote:
> Thanks for the quick reply George!
> 
> We could, but the data is still available, in this case a file,
> versus in the output of "ps -ef | grep java".  We can obviously
> encrypt the sensitive information.

Use sane file permissions?

While you are at it, why not just put the db username and password
into your application's META-INF/context.xml file where they belong?

> One idea, in order to support injecting Environment Variables would
> be to support a syntax of
> 
> ${env.DB_USER}
> 
> where if the subsitution property starts with "env", then the
> variable could be retrieve by System.getEnv(...) otherwise
> System.getProperty(...).

We *could* do that, but why?

Is there a reason to think that file permissions are easier to break
than, well, file permissions (think /proc/[pid]/environ)?

- -chris

> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev
>  wrote:
> 
>> Can you use catalina.properties? From the docs [1]
>> 
>> " All system properties are available including those set using
>> the -D syntax, those automatically made available by the JVM and
>> those configured in the $CATALINA_BASE/conf/catalina.properties
>> file."
>> 
>> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>> 
>> 
>> -Original Message- From: Algirdas Veitas
>> [mailto:apvei...@gmail.com] Sent: Monday, January 22, 2018 4:02
>> PM To: users@tomcat.apache.org Subject: Using Environment
>> variables instead of Java -D properties for context.xml
>> substitution
>> 
>> Hi,
>> 
>> We have a context.xml under $TOMCAT_HOME/conf that looks like
>> this:
>> 
>> > type="javax.sql.DataSource" username="${DB_USERNAME}" 
>> password="${DB_PASSWORD}" 
>> driverClassName="oracle.jdbc.OracleDriver" 
>> validationQuery="select 1 from dual" testOnBorrow="true" 
>> url="${DB_URL}" />
>> 
>> if we do something like this in setenv.sh, the substitution works
>> great
>> 
>> export DB_USERNAME=xyz export DB_PASSWORD=vvv
>> 
>> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME" export
>> JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
>> 
>> However, if on a linux box, if someone did a "ps -ef | grep
>> java", they would be able to see the actual values of these
>> parameters.
>> 
>> theuser 127734  1  0 Jan19 ?00:04:39
>> /opt/java/bin/java 
>> -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/ 
>> tomcat/apache-tomcat/conf/logging.properties 
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>
>> 
- -DDB_USERNAME=xyz
>> -DDB_PASSWORD=vvv
>> 
>> Which our operations team does not want
>> 
>> Is there any syntax that Tomcat can recognize to substitute true 
>> environment variables (i.e. export DB_USERNAME=xyz) as opposed to
>> Java properties injected into the JVM by -D (i.e. export 
>> DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any
>> documentation on it, but thought would ask.
>> 
>> Thanks in advance, Al
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnXV0dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjcvQ/8Dtu3ftae5LDBrqLD
AZlkomVg2RnuaASPRIeX+wyDsT7+ojjIknJy3l2pw3z9F/7qp98JZR7AsDb8V+ma
ifRuxWEUrfpHmf+Mant+1DlgF56B+o9zMJevD435XwJiH2P2G6OBnopYvq5StDlN
GF0JN+HUtceastqw91P3SRj9DS8q2K36F6b75r5I+JmDXoDHecbtVXxMMwq55u6l
jXY/FzIUAfxmJnsiWZaYZ2+oFdwe4rWxe6vLTKUyAi17w3g7UcXHpXHzq4s7YlKO
zfqkThTnOUi9loRKQSzfOb6kIDMSmM+MHZ/JrXqRrPQ0h1GxOaea4Wnp5rBg4TBI
1fkCiSLbv6oa+olZsIqZCVESSSO1yeZYRkAolENqMyRX+vlDjzKJehyIF8LlsnvY
TjITzqEYsp9xSC15JU1OACmRdkOr9d/dS+5hoKT96cfu11Y+bt5My2lYvxUzGHCH
crdTs4j8C5TPN4mksasOOEfuEg5aad0nj5x2lb4meZwUGiQYxmn13JV8c7I0skOM
NtJX2kSxOLFFIpHZpPbY+cds2oYkfZOGFAKjcye7SGRGhuGFMfGohzZDbXIcgMVK
DeioYT+gc+r6Y2gSvzRPISdlzEeRi4oPrXM42vsRs2qvOaacManAqqIOhdAHdPsZ
a4mP2K3f7yHoWBxCG3zhxjli56o=
=MG1G
-END PGP SIGNATURE-

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

Re: Fw: No movement at Debug mode

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Karen,

On 1/21/18 10:49 AM, Karen Goh wrote:
> I want to add in additional infor :
> 
> After I stopped the server, the console has the following error
> message which beats me.
> 
> WARNING: The web application [Hi5S] appears to have started a
> thread named [Abandoned connection cleanup thread] but has failed
> to stop it. This is very likely to create a memory leak. Stack
> trace of thread: java.io.WinNTFileSystem.canonicalize0(Native
> Method) 
> java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:428) 
> java.io.File.getCanonicalPath(File.java:618) 
> org.apache.catalina.webresources.AbstractFileResourceSet.file(Abstract
FileResourceSet.java:90)
>
> 
org.apache.catalina.webresources.DirResourceSet.getResource(DirResourceS
et.java:101)
> org.apache.catalina.webresources.StandardRoot.getResourceInternal(Stan
dardRoot.java:281)
>
> 
org.apache.catalina.webresources.CachedResource.validateResource(CachedR
esource.java:97)
> org.apache.catalina.webresources.Cache.getResource(Cache.java:69) 
> org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot
.java:216)
>
> 
org.apache.catalina.webresources.StandardRoot.getClassLoaderResource(Sta
ndardRoot.java:225)
> org.apache.catalina.loader.WebappClassLoaderBase.findResource(WebappCl
assLoaderBase.java:884)
>
> 
org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClass
LoaderBase.java:1005)
> com.mysql.jdbc.AbandonedConnectionCleanupThread.checkContextClassLoade
rs(AbandonedConnectionCleanupThread.java:90)
>
> 
com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionC
leanupThread.java:63)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
ava:1149)
>
> 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
va:624)
> java.lang.Thread.run(Thread.java:748)
> 
> I hope with the new infor, this group will be able to help me
> resolve the error.

The MySQL Connector/J simply has a bug. Upgrade to the latest version
to see if they have fixed it.

I gave up trying to convince them that it was a problem and that they
needed to fix it, because I guess they fundamentally don't understand
what it means to want to be able to "completely deregister the driver
and shutdown all threads".

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

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpnW44dHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFh/hhAAnU0DsarH7K7NzsnG
AQxptKGl9bBtw/es2D8OdvO73XzOUD4MDO1HB3rRKNaMA6Ld/Ea1SNJb+6V2DqRH
aG4ppx82OWfasoK7ywlQB/k7eOERbwjIQHLOx5+N0JHwotqN83dVDeCSdd0TWHzu
7o/NWRQLRgAmoNYPe8civV3Kur5Ci+v7QlA3PeHtzOlfjYwwvNU8ZTX4XAiUA9zG
HxL2jlz6cDfVd/rFw8O3q7r4fS4Im70OS4M6midSStGR+VyVDRExY8yqrh/q4sC8
e1rTFs12amf7yqnN8KbVHgpDF4RBIg8zGbqOdtXng4oXcpjsYCtfaWvVr4xFLdhn
tS6vzAFIoHhRwOzsjadcluPrwxG7PLxcIbXbKPpgel21WWeg8imXE3QGa5eGoy91
BLuoLsLBLDO002uw+OPKIZzTZ5yM0EyXuqlr46C7Oc46iNg7Ub39DYC5eXHYmLc+
fh+oazznZJoTaSlZmGPJxosuBYfs70iQx+WIlzI9ggzg8Q1QdhUcFrwJImwe5S3V
YuydGr5VUFhIJQ4rVxyvX1r160K695oT7Y6RIEdPcRInodSmqaGVcm0jWZVKuPMw
1NvgUmUBnD0xElvOIRxWs7p5hjSVvMlxhmWFdamDwr4TPYvBIGRIl0Z7fikV/i2q
vlgjFKJpMXfCppBXuyxPOsS/MA4=
=0gps
-END PGP SIGNATURE-

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

logging on shutdown

[Greg Huber]

Hello,

I tried the latest version 9.0.4,  one thing I have noticed that it does
not log any output when I shut down the server.  Also Rechecking version
8.5.24 and also now does not log any output.

The server is shutting down correctly as its calling my context finalise
listener contextDestroyed() and cleaning up search lock files etc.

My logging is working as I can see the startup messages. I have a basic
install with no changes to conf dir files.

Any ideas?

Cheers Greg

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

It does turtle all the way downbut it would "solve" having sensitive
information on the Tomcat server exposed either in a file or via "ps -ef |
grep java"  (and make sure they are not logged by Tomcat in the logs).

Whether using the original sequence of commands shown or "prompting the
operations persons(s)" as Andre suggested, the total amount of time that
the sensitive information would be exposed "in the clear" would be
minimized to seconds before a restart and seconds after Tomcat and it's web
applications have been successfully deployed.



On Tue, Jan 23, 2018 at 8:40 AM, André Warnier (tomcat) 
wrote:

> Hi.
>
> Ok, so let's recurse..
>
> On 23.01.2018 13:27, Algirdas Veitas wrote:
>
>> Andre, my apologies for bringing up a topic that has been repeated ad
>> nauseum.
>>
>> We were thinking of a process like the following, which would eliminate
>> "the information has to available somewhere in a file" on the actual
>> server
>> where Tomcat is running.
>>
>> cd $TOMCAT_HOME/bin
>>> set +o history
>>> export DB_USERNAME=xyz
>>> ./startup.sh
>>>
>> . once the process has started
>>
>>>   unset DB_USERNAME
>>> set -o history
>>>
>>
>> This process does not eliminate the need to store the values of sensitive
>> information.  But by supporting environment variables, one could eliminate
>> using catalina.properties or -DDB_USERNAME, which exposes the information
>> on the server.  In our case, operations would get the data from a secure
>> vault and then run the above scripts.  I suppose we could get the same
>> effect by modifying catalina.properties, starting the server and then
>> clearing catalina.properties, until the next restart...
>>
>>
> When you mention "operations", you are talking about some persons, right ?
> I omitted to mention this solution before, because it means, in the
> practice, that someone has to be available, to restart Tomcat (for example,
> after a system reboot, an update etc..). So this is not really scalable.
> In such a case, the Tomcat startup script could also just prompt the
> "operations" for the userid/password, on the console. No need to add the
> complexity of an encrypted vault.
> Of course, it means that you need a group of people sharing that role,
> because persons go on holidays sometimes. And unless the sensitive
> information is trivial to remember (and thus insecure), it will need to be
> written down somewhere. As would the password for the secure vault.
>
> It is turtles all the way down.
>
>
> Don't want to restart an old thread, so if preferred, we can stop the
>> discussion.  Thank you for your time.
>>
>> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
>> wrote:
>>
>> Hi.
>>>
>>> On 23.01.2018 12:11, Algirdas Veitas wrote:
>>>
>>> Thanks for the quick reply George!

 We could, but the data is still available, in this case a file, versus
 in
 the output of "ps -ef | grep java".  We can obviously encrypt the
 sensitive
 information.

 One idea, in order to support injecting Environment Variables would be
 to
 support a syntax of

 ${env.DB_USER}

 where if the subsitution property starts with "env", then the variable
 could be retrieve by System.getEnv(...) otherwise
 System.getProperty(...).


 and where does the environment variable value come from ?
>>>
>>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue
>>> that
>>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>>> already ?
>>>
>>> Wherever you put any kind of "sensitive" information, in the end it has
>>> to
>>> be available *somewhere* for Tomcat (or any other server) to read. And if
>>> you encrypt it, then the key for decrypting it has to be available
>>> somewhere also.
>>> And the answer to that, is always the same in the end, no matter how many
>>> recursions you go through : the information has to be available somewhere
>>> in a file, readable *only* by the user-id under which the server runs
>>> (and
>>> of course whoever can create such a file).
>>> And if someone not authorized to do so, has access to that file, then you
>>> have bigger problems than just with the server software.
>>>
>>>
>>>
>>>


 On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
 wrote:

 Can you use catalina.properties? From the docs [1]

>
> " All system properties are available including those set using the -D
> syntax, those automatically made available by the JVM and those
> configured
> in the $CATALINA_BASE/conf/catalina.properties file."
>
> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>
>
> -Original Message-
> From: Algirdas Veitas [mailto:apvei...@gmail.com]
> Sent: Monday, January 22, 2018 4:02 PM
> To: users@tomcat.apache.org
> Subject: Using Environment variables instead of Java -D properties for

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Mark H. Wood]

Well, there are several layers of problems here, with different ways
of addressing them.

Command lines are available using 'ps', so any secrets written on the
command line are visible to anyone able to get a session on that host,
for the duration of the command.  There's no way around this that I
know of.

Process environment variables may also be visible to all and sundry,
so moving secrets from the command line to the environment just makes
slightly more work for the snooper.  Removing them from the shell's
environment after use may not help, because typically the environment
is cloned when a process is forked, so the service process will have
copies that aren't removed.

The people who wrote the Servlet spec. seem to me to have been
thinking that the context for an instance of an app. would be
generated by an installer program or by the container's management
tools.  You could write a simple script to generate a context
declaration which is customized for a specific instance.  Unlike the
command line or the process environment, files (such as a
free-standing context declaration) can be protected by the
filesystem.  This is your best noninteractive bet.

As mentioned by another, the way to limit availability of
machine-readable secrets to the greatest extent is to require an
operator to type them in at startup.  However, you'll need to consider
the consequences of this if your container is automatically started at
system startup -- you may need a way to let an individual context's
startup wait for an operator to appear without hanging the whole
system startup procedure.  (Automatic startup is another common thing
that the spec. authors seem to have believed to be Somebody Else's
Problem.)

For completeness:  in your own code, you'll also wish to ensure that
you obliterate (not just discard) secrets as soon as you have no
further need for them.  That means that, within the JVM, they should
only ever exist in mutable objects (not String, for example).

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[tomcat]

Hi.

Ok, so let's recurse..

On 23.01.2018 13:27, Algirdas Veitas wrote:

Andre, my apologies for bringing up a topic that has been repeated ad
nauseum.

We were thinking of a process like the following, which would eliminate
"the information has to available somewhere in a file" on the actual server
where Tomcat is running.


cd $TOMCAT_HOME/bin
set +o history
export DB_USERNAME=xyz
./startup.sh

. once the process has started

  unset DB_USERNAME
set -o history


This process does not eliminate the need to store the values of sensitive
information.  But by supporting environment variables, one could eliminate
using catalina.properties or -DDB_USERNAME, which exposes the information
on the server.  In our case, operations would get the data from a secure
vault and then run the above scripts.  I suppose we could get the same
effect by modifying catalina.properties, starting the server and then
clearing catalina.properties, until the next restart...



When you mention "operations", you are talking about some persons, right ?
I omitted to mention this solution before, because it means, in the practice, that someone 
has to be available, to restart Tomcat (for example, after a system reboot, an update 
etc..). So this is not really scalable.
In such a case, the Tomcat startup script could also just prompt the "operations" for the 
userid/password, on the console. No need to add the complexity of an encrypted vault.
Of course, it means that you need a group of people sharing that role, because persons go 
on holidays sometimes. And unless the sensitive information is trivial to remember (and 
thus insecure), it will need to be written down somewhere. As would the password for the 
secure vault.


It is turtles all the way down.


Don't want to restart an old thread, so if preferred, we can stop the
discussion.  Thank you for your time.

On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
wrote:


Hi.

On 23.01.2018 12:11, Algirdas Veitas wrote:


Thanks for the quick reply George!

We could, but the data is still available, in this case a file, versus in
the output of "ps -ef | grep java".  We can obviously encrypt the
sensitive
information.

One idea, in order to support injecting Environment Variables would be to
support a syntax of

${env.DB_USER}

where if the subsitution property starts with "env", then the variable
could be retrieve by System.getEnv(...) otherwise System.getProperty(...).



and where does the environment variable value come from ?

Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
has been repeated ad nauseam over hundreds of posts on dozens of forums
already ?

Wherever you put any kind of "sensitive" information, in the end it has to
be available *somewhere* for Tomcat (or any other server) to read. And if
you encrypt it, then the key for decrypting it has to be available
somewhere also.
And the answer to that, is always the same in the end, no matter how many
recursions you go through : the information has to be available somewhere
in a file, readable *only* by the user-id under which the server runs (and
of course whoever can create such a file).
And if someone not authorized to do so, has access to that file, then you
have bigger problems than just with the server software.







On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
wrote:

Can you use catalina.properties? From the docs [1]


" All system properties are available including those set using the -D
syntax, those automatically made available by the JVM and those
configured
in the $CATALINA_BASE/conf/catalina.properties file."

[1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html


-Original Message-
From: Algirdas Veitas [mailto:apvei...@gmail.com]
Sent: Monday, January 22, 2018 4:02 PM
To: users@tomcat.apache.org
Subject: Using Environment variables instead of Java -D properties for
context.xml substitution

Hi,

We have a context.xml under $TOMCAT_HOME/conf that looks like this:



if we do something like this in setenv.sh, the substitution works great

export DB_USERNAME=xyz
export DB_PASSWORD=vvv

export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"

However, if on a linux box, if someone did a "ps -ef | grep java", they
would be able to see the actual values of these parameters.

theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
-Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
tomcat/apache-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-DDB_USERNAME=xyz
-DDB_PASSWORD=vvv

Which our operations team does not want

Is there any syntax that Tomcat can recognize to substitute true
environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
properties injected into the JVM by -D (i.e. export
DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any documentation
on it, but 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Konstantin Kolinko]

2018-01-23 16:14 GMT+03:00 Peter Kreuser :
> BTW:
>
>
>> Am 23.01.2018 um 13:56 schrieb Peter Kreuser :
>>
>> Algirdas,
>>
>>
>>
>>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
>>>
>>> Andre, my apologies for bringing up a topic that has been repeated ad
>>> nauseum.
>>>
>>> We were thinking of a process like the following, which would eliminate
>>> "the information has to available somewhere in a file" on the actual server
>>> where Tomcat is running.
>>>
 cd $TOMCAT_HOME/bin
 set +o history
 export DB_USERNAME=xyz
 ./startup.sh
>>> . once the process has started
 unset DB_USERNAME
 set -o history
>>>
>>> This process does not eliminate the need to store the values of sensitive
>>> information.  But by supporting environment variables, one could eliminate
>>> using catalina.properties or -DDB_USERNAME, which exposes the information
>>> on the server.  In our case, operations would get the data from a secure
>>> vault and then run the above scripts.  I suppose we could get the same
>>> effect by modifying catalina.properties, starting the server and then
>>> clearing catalina.properties, until the next restart...
>>
>> Where would you put that script with the text?
>> Well if you use a secure vault, then that script would have to know the 
>> password to the full secure vault...
>>
>> You get a feel for the problem?
>>
>> Run Tomcat in a dedicated service user, make the conf only readable for him 
>> and restrict the access to the user’s home/tomcat dirs...
>>
>> The admins of the server will have access to all the information anyhow. But 
>> any other users around will not be able to read the conf, even the java opts 
>> of the process will be invisible.
>>
>> Just my 2cts.
>>
>> Peter
>
> the commandline parameters (-D) are also in the tomcat logs, thus probably in 
> your backups and archives.
>

VersionLoggerListener can also be configured to log the environment
variables with logEnv="true". It is not the default setting though.


> ad nauseum.

The FAQ page:
https://wiki.apache.org/tomcat/FAQ/Password


Best regards,
Konstantin Kolinko

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

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

BTW:


> Am 23.01.2018 um 13:56 schrieb Peter Kreuser :
> 
> Algirdas,
> 
> 
> 
>> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
>> 
>> Andre, my apologies for bringing up a topic that has been repeated ad
>> nauseum.
>> 
>> We were thinking of a process like the following, which would eliminate
>> "the information has to available somewhere in a file" on the actual server
>> where Tomcat is running.
>> 
>>> cd $TOMCAT_HOME/bin
>>> set +o history
>>> export DB_USERNAME=xyz
>>> ./startup.sh
>> . once the process has started
>>> unset DB_USERNAME
>>> set -o history
>> 
>> This process does not eliminate the need to store the values of sensitive
>> information.  But by supporting environment variables, one could eliminate
>> using catalina.properties or -DDB_USERNAME, which exposes the information
>> on the server.  In our case, operations would get the data from a secure
>> vault and then run the above scripts.  I suppose we could get the same
>> effect by modifying catalina.properties, starting the server and then
>> clearing catalina.properties, until the next restart...
> 
> Where would you put that script with the text?
> Well if you use a secure vault, then that script would have to know the 
> password to the full secure vault...
> 
> You get a feel for the problem?
> 
> Run Tomcat in a dedicated service user, make the conf only readable for him 
> and restrict the access to the user’s home/tomcat dirs...
> 
> The admins of the server will have access to all the information anyhow. But 
> any other users around will not be able to read the conf, even the java opts 
> of the process will be invisible.
> 
> Just my 2cts.
> 
> Peter

the commandline parameters (-D) are also in the tomcat logs, thus probably in 
your backups and archives.

Peter 

>> Don't want to restart an old thread, so if preferred, we can stop the
>> discussion.  Thank you for your time.
>> 
>> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
>> wrote:
>> 
>>> Hi.
>>> 
 On 23.01.2018 12:11, Algirdas Veitas wrote:
 
 Thanks for the quick reply George!
 
 We could, but the data is still available, in this case a file, versus in
 the output of "ps -ef | grep java".  We can obviously encrypt the
 sensitive
 information.
 
 One idea, in order to support injecting Environment Variables would be to
 support a syntax of
 
 ${env.DB_USER}
 
 where if the subsitution property starts with "env", then the variable
 could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
>>> and where does the environment variable value come from ?
>>> 
>>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
>>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>>> already ?
>>> 
>>> Wherever you put any kind of "sensitive" information, in the end it has to
>>> be available *somewhere* for Tomcat (or any other server) to read. And if
>>> you encrypt it, then the key for decrypting it has to be available
>>> somewhere also.
>>> And the answer to that, is always the same in the end, no matter how many
>>> recursions you go through : the information has to be available somewhere
>>> in a file, readable *only* by the user-id under which the server runs (and
>>> of course whoever can create such a file).
>>> And if someone not authorized to do so, has access to that file, then you
>>> have bigger problems than just with the server software.
>>> 
>>> 
>>> 
 
 
 
 On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
 wrote:
 
 Can you use catalina.properties? From the docs [1]
> 
> " All system properties are available including those set using the -D
> syntax, those automatically made available by the JVM and those
> configured
> in the $CATALINA_BASE/conf/catalina.properties file."
> 
> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
> 
> 
> -Original Message-
> From: Algirdas Veitas [mailto:apvei...@gmail.com]
> Sent: Monday, January 22, 2018 4:02 PM
> To: users@tomcat.apache.org
> Subject: Using Environment variables instead of Java -D properties for
> context.xml substitution
> 
> Hi,
> 
> We have a context.xml under $TOMCAT_HOME/conf that looks like this:
> 
>   auth="Container"
>  type="javax.sql.DataSource"
>  username="${DB_USERNAME}"
>  password="${DB_PASSWORD}"
>  driverClassName="oracle.jdbc.OracleDriver"
>  validationQuery="select 1 from dual"
>  testOnBorrow="true"
>  url="${DB_URL}"
> />
> 
> if we do something like this in setenv.sh, the substitution works great
> 
> export DB_USERNAME=xyz
> export DB_PASSWORD=vvv
> 
> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
> export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
> 

[ANN] Apache Tomcat 9.0.4 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.4. This is the first stable release of the 9.0.x series.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language, Java
WebSocket and JASPIC technologies.

Apache Tomcat 9.0.4 is a bugfix and feature release. The notable changes
compared to
9.0.2 include:

- Modify the Default and WebDAV Servlets so that a 405 status code is
  returned for PUT and DELETE requests when disabled via the readonly
  initialisation parameter.

- Add support for GZIP compression with HTTP/2

- Expand the TLS functionality exposed via the Manager application

- Return a simple, plain text error message if a client attempts to make
  a plain text HTTP connection to a TLS enabled NIO or NIO2 Connector.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 7.x and 8.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Peter Kreuser]

Algirdas,



> Am 23.01.2018 um 13:27 schrieb Algirdas Veitas :
> 
> Andre, my apologies for bringing up a topic that has been repeated ad
> nauseum.
> 
> We were thinking of a process like the following, which would eliminate
> "the information has to available somewhere in a file" on the actual server
> where Tomcat is running.
> 
>> cd $TOMCAT_HOME/bin
>> set +o history
>> export DB_USERNAME=xyz
>> ./startup.sh
> . once the process has started
>> unset DB_USERNAME
>> set -o history
> 
> This process does not eliminate the need to store the values of sensitive
> information.  But by supporting environment variables, one could eliminate
> using catalina.properties or -DDB_USERNAME, which exposes the information
> on the server.  In our case, operations would get the data from a secure
> vault and then run the above scripts.  I suppose we could get the same
> effect by modifying catalina.properties, starting the server and then
> clearing catalina.properties, until the next restart...
> 

Where would you put that script with the text?
Well if you use a secure vault, then that script would have to know the 
password to the full secure vault...

You get a feel for the problem?

Run Tomcat in a dedicated service user, make the conf only readable for him and 
restrict the access to the user’s home/tomcat dirs...

The admins of the server will have access to all the information anyhow. But 
any other users around will not be able to read the conf, even the java opts of 
the process will be invisible.

Just my 2cts.

Peter
> Don't want to restart an old thread, so if preferred, we can stop the
> discussion.  Thank you for your time.
> 
> On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
> wrote:
> 
>> Hi.
>> 
>>> On 23.01.2018 12:11, Algirdas Veitas wrote:
>>> 
>>> Thanks for the quick reply George!
>>> 
>>> We could, but the data is still available, in this case a file, versus in
>>> the output of "ps -ef | grep java".  We can obviously encrypt the
>>> sensitive
>>> information.
>>> 
>>> One idea, in order to support injecting Environment Variables would be to
>>> support a syntax of
>>> 
>>> ${env.DB_USER}
>>> 
>>> where if the subsitution property starts with "env", then the variable
>>> could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
>>> 
>>> 
>> and where does the environment variable value come from ?
>> 
>> Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
>> has been repeated ad nauseam over hundreds of posts on dozens of forums
>> already ?
>> 
>> Wherever you put any kind of "sensitive" information, in the end it has to
>> be available *somewhere* for Tomcat (or any other server) to read. And if
>> you encrypt it, then the key for decrypting it has to be available
>> somewhere also.
>> And the answer to that, is always the same in the end, no matter how many
>> recursions you go through : the information has to be available somewhere
>> in a file, readable *only* by the user-id under which the server runs (and
>> of course whoever can create such a file).
>> And if someone not authorized to do so, has access to that file, then you
>> have bigger problems than just with the server software.
>> 
>> 
>> 
>>> 
>>> 
>>> 
>>> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
>>> wrote:
>>> 
>>> Can you use catalina.properties? From the docs [1]
 
 " All system properties are available including those set using the -D
 syntax, those automatically made available by the JVM and those
 configured
 in the $CATALINA_BASE/conf/catalina.properties file."
 
 [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
 
 
 -Original Message-
 From: Algirdas Veitas [mailto:apvei...@gmail.com]
 Sent: Monday, January 22, 2018 4:02 PM
 To: users@tomcat.apache.org
 Subject: Using Environment variables instead of Java -D properties for
 context.xml substitution
 
 Hi,
 
 We have a context.xml under $TOMCAT_HOME/conf that looks like this:
 
 >>>auth="Container"
type="javax.sql.DataSource"
username="${DB_USERNAME}"
password="${DB_PASSWORD}"
driverClassName="oracle.jdbc.OracleDriver"
validationQuery="select 1 from dual"
testOnBorrow="true"
url="${DB_URL}"
 />
 
 if we do something like this in setenv.sh, the substitution works great
 
 export DB_USERNAME=xyz
 export DB_PASSWORD=vvv
 
 export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
 export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
 
 However, if on a linux box, if someone did a "ps -ef | grep java", they
 would be able to see the actual values of these parameters.
 
 theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
 -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
 

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

Andre, my apologies for bringing up a topic that has been repeated ad
nauseum.

We were thinking of a process like the following, which would eliminate
"the information has to available somewhere in a file" on the actual server
where Tomcat is running.

> cd $TOMCAT_HOME/bin
> set +o history
> export DB_USERNAME=xyz
> ./startup.sh
. once the process has started
>  unset DB_USERNAME
> set -o history

This process does not eliminate the need to store the values of sensitive
information.  But by supporting environment variables, one could eliminate
using catalina.properties or -DDB_USERNAME, which exposes the information
on the server.  In our case, operations would get the data from a secure
vault and then run the above scripts.  I suppose we could get the same
effect by modifying catalina.properties, starting the server and then
clearing catalina.properties, until the next restart...

Don't want to restart an old thread, so if preferred, we can stop the
discussion.  Thank you for your time.

On Tue, Jan 23, 2018 at 6:50 AM, André Warnier (tomcat) 
wrote:

> Hi.
>
> On 23.01.2018 12:11, Algirdas Veitas wrote:
>
>> Thanks for the quick reply George!
>>
>> We could, but the data is still available, in this case a file, versus in
>> the output of "ps -ef | grep java".  We can obviously encrypt the
>> sensitive
>> information.
>>
>> One idea, in order to support injecting Environment Variables would be to
>> support a syntax of
>>
>> ${env.DB_USER}
>>
>> where if the subsitution property starts with "env", then the variable
>> could be retrieve by System.getEnv(...) otherwise System.getProperty(...).
>>
>>
> and where does the environment variable value come from ?
>
> Isn't this the forever-recurring same "chicken-and-egg" kind of issue that
> has been repeated ad nauseam over hundreds of posts on dozens of forums
> already ?
>
> Wherever you put any kind of "sensitive" information, in the end it has to
> be available *somewhere* for Tomcat (or any other server) to read. And if
> you encrypt it, then the key for decrypting it has to be available
> somewhere also.
> And the answer to that, is always the same in the end, no matter how many
> recursions you go through : the information has to be available somewhere
> in a file, readable *only* by the user-id under which the server runs (and
> of course whoever can create such a file).
> And if someone not authorized to do so, has access to that file, then you
> have bigger problems than just with the server software.
>
>
>
>>
>>
>>
>> On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
>> wrote:
>>
>> Can you use catalina.properties? From the docs [1]
>>>
>>> " All system properties are available including those set using the -D
>>> syntax, those automatically made available by the JVM and those
>>> configured
>>> in the $CATALINA_BASE/conf/catalina.properties file."
>>>
>>> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>>>
>>>
>>> -Original Message-
>>> From: Algirdas Veitas [mailto:apvei...@gmail.com]
>>> Sent: Monday, January 22, 2018 4:02 PM
>>> To: users@tomcat.apache.org
>>> Subject: Using Environment variables instead of Java -D properties for
>>> context.xml substitution
>>>
>>> Hi,
>>>
>>> We have a context.xml under $TOMCAT_HOME/conf that looks like this:
>>>
>>> >> auth="Container"
>>> type="javax.sql.DataSource"
>>> username="${DB_USERNAME}"
>>> password="${DB_PASSWORD}"
>>> driverClassName="oracle.jdbc.OracleDriver"
>>> validationQuery="select 1 from dual"
>>> testOnBorrow="true"
>>> url="${DB_URL}"
>>> />
>>>
>>> if we do something like this in setenv.sh, the substitution works great
>>>
>>> export DB_USERNAME=xyz
>>> export DB_PASSWORD=vvv
>>>
>>> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
>>> export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
>>>
>>> However, if on a linux box, if someone did a "ps -ef | grep java", they
>>> would be able to see the actual values of these parameters.
>>>
>>> theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
>>> -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
>>> tomcat/apache-tomcat/conf/logging.properties
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>> -DDB_USERNAME=xyz
>>> -DDB_PASSWORD=vvv
>>>
>>> Which our operations team does not want
>>>
>>> Is there any syntax that Tomcat can recognize to substitute true
>>> environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
>>> properties injected into the JVM by -D (i.e. export
>>> DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any documentation
>>> on it, but thought would ask.
>>>
>>> Thanks in advance,
>>> Al
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Re: A question about The Relationship between Http Session and WebSocket Session

[tong__...@163.com]

OK Thanks Mark！



tong__...@163.com
 
From: Mark Thomas
Date: 2018-01-23 20:02
To: users
Subject: Re: A question about The Relationship between Http Session and 
WebSocket Session
On 23/01/18 10:35, tong__hui wrote:
> Hello, 
> I'm a J2EE Programmer use Tomcat deploy my webapplication.
> I have a question about the relationship between Http Session and WebSocket 
> Session in tomcat.
> Is  Http Session contains WebSocket Session? or they are seperate.
 
They are completely separate.
 
Mark
 
 
> 
> Please help me!
> 
> Thank you very much!
> 
> Server version: Apache Tomcat/7.0.81
> Server built:   Aug 11 2017 10:21:27 UTC
> Server number:  7.0.81.0
> OS Name:Linux
> OS Version: 2.6.32-504.el6.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_25-b17
> JVM Vendor: Oracle Corporation
> -
> 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: No movement at Debug mode

[Karen Goh]

On Sun, 1/21/18, Alex O'Ree  wrote:

 Subject: Re: No movement at Debug mode
 To: "Tomcat Users List" , "Karen Goh" 

 Date: Sunday, January 21, 2018, 11:44 PM
 
 Do you mean you cannot get a
 debugger to attach to Tomcat and thus step
 through your app?
 Make sure you
 start tomcat with "catalina jpda run". I think it
 listens on
 port 8000 by default. You can
 then use just about any IDE to attach the
 debugger via JPDA to localhost port 8000.

Hi Alex,

Actually, I found out that there is actually debugging going on cos I found out 
in the Tomcat log the following details :

127.0.0.1 - - [23/Jan/2018:12:14:49 +0800] "GET / HTTP/1.1" 404 1074
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET /Hi5S/tutorRegister.jsp 
HTTP/1.1" 200 13656
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET 
/Hi5S/BootStrap/bootstrap-multiselect.js HTTP/1.1" 404 1121
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET 
/Hi5S/BootStrap/Checkbox.js HTTP/1.1" 404 1108
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET /Hi5S/js/jquery.js 
HTTP/1.1" 404 1099
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET /Hi5S/js/bootstrap.min.js 
HTTP/1.1" 404 1106
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET 
/Hi5S/js/jqBootstrapValidation.js HTTP/1.1" 404 1114
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET /Hi5S/js/contact_me.js 
HTTP/1.1" 404 1103
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:14:51 +0800] "GET /Hi5S/Image/aa1.png 
HTTP/1.1" 404 1100
0:0:0:0:0:0:0:1 - - [23/Jan/2018:12:16:36 +0800] "POST /Hi5S/addTutor HTTP/1.1" 
200 -

But, I could not understand why Tomcat can't read the URL tutorRegister.jsp, as 
there is a 404.

I have make sure I have all the right thing in my web.xml as follows :

http://xmlns.jcp.org/xml/ns/javaee;
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
 http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd;
 version="3.1">
  Hi5S
  
tutorRegister.jsp
index.html
  index.htm
  index.jsp
  
  
 MySQL Datasource
 jdbc/hi5s
 javax.sql.DataSource
 Container

  

I have used the option of use workspace meta data for my tomcat server location 
and it does shows the 2 folders : ROOTS and the project name : Hi5S folders 
inside 

C:\Users\\workspace5\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps

So, why is tomcat not able to read the URL ?

Hope that you could tell me the way to resolve this.  

Thanks & regards,
Karen
 
 On Sun, Jan 21, 2018 at 10:37 AM, Karen Goh
 
 wrote:
 
 > Hi
 expert,
 >
 > I have
 been stuck at this problem - No debug movement , for quite
 some
 > time and am seeking help from this
 user group.
 >
 > After
 submitting my form using JSP,
 >
 > So, here's what appeared at the
 console :
 >
 > an 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Server
 version:        Apache Tomcat/8.5.24
 > Jan 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Server
 built:          Nov 27 2017 13:05:30 UTC
 > Jan 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Server
 number:         8.5.24.0
 > Jan 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: OS Name: 
              Windows 10
 > Jan 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: OS
 Version:            10.0
 > Jan 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO:
 Architecture:          amd64
 > Jan
 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Java
 Home:             C:\Program
 Files\Java\jdk1.8.0_151\jre
 > Jan 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: JVM
 Version:           1.8.0_151-b12
 >
 Jan 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: JVM
 Vendor:            Oracle Corporation
 > Jan 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO:
 CATALINA_BASE:        
 C:\Users\Karen.Goh\workspace5\Servers2\Tomcat
 > v8.5 Server at
 localhost-config\Hi5SProject
 > Jan 21,
 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO:
 CATALINA_HOME:         C:\Program
 Files\Apache\apache-tomcat-8.5.24
 > Jan
 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Command
 line argument: -agentlib:jdwp=transport=dt_
 >
 socket,suspend=y,address=localhost:51917
 > Jan 21, 2018 11:25:58 PM
 org.apache.catalina.startup.VersionLoggerListener
 > log
 > INFO: Command
 line argument: -Dcatalina.base=C:\Users\
 > Karen.Goh\workspace5\Servers2\Tomcat v8.5
 Server at
 >
 localhost-config\Hi5SProject
 > Jan 21,
 2018 11:25:58 PM
 

Re: A question about The Relationship between Http Session and WebSocket Session

[Mark Thomas]

On 23/01/18 10:35, tong__hui wrote:
> Hello, 
> I'm a J2EE Programmer use Tomcat deploy my webapplication.
> I have a question about the relationship between Http Session and WebSocket 
> Session in tomcat.
> Is  Http Session contains WebSocket Session? or they are seperate.

They are completely separate.

Mark


> 
> Please help me!
> 
> Thank you very much!
> 
> Server version: Apache Tomcat/7.0.81
> Server built:   Aug 11 2017 10:21:27 UTC
> Server number:  7.0.81.0
> OS Name:Linux
> OS Version: 2.6.32-504.el6.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_25-b17
> JVM Vendor: Oracle Corporation
> -
> 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: Using Environment variables instead of Java -D properties for context.xml substitution

[tomcat]

Hi.

On 23.01.2018 12:11, Algirdas Veitas wrote:

Thanks for the quick reply George!

We could, but the data is still available, in this case a file, versus in
the output of "ps -ef | grep java".  We can obviously encrypt the sensitive
information.

One idea, in order to support injecting Environment Variables would be to
support a syntax of

${env.DB_USER}

where if the subsitution property starts with "env", then the variable
could be retrieve by System.getEnv(...) otherwise System.getProperty(...).



and where does the environment variable value come from ?

Isn't this the forever-recurring same "chicken-and-egg" kind of issue that has been 
repeated ad nauseam over hundreds of posts on dozens of forums already ?


Wherever you put any kind of "sensitive" information, in the end it has to be available 
*somewhere* for Tomcat (or any other server) to read. And if you encrypt it, then the key 
for decrypting it has to be available somewhere also.
And the answer to that, is always the same in the end, no matter how many recursions you 
go through : the information has to be available somewhere in a file, readable *only* by 
the user-id under which the server runs (and of course whoever can create such a file).
And if someone not authorized to do so, has access to that file, then you have bigger 
problems than just with the server software.







On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
wrote:


Can you use catalina.properties? From the docs [1]

" All system properties are available including those set using the -D
syntax, those automatically made available by the JVM and those configured
in the $CATALINA_BASE/conf/catalina.properties file."

[1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html


-Original Message-
From: Algirdas Veitas [mailto:apvei...@gmail.com]
Sent: Monday, January 22, 2018 4:02 PM
To: users@tomcat.apache.org
Subject: Using Environment variables instead of Java -D properties for
context.xml substitution

Hi,

We have a context.xml under $TOMCAT_HOME/conf that looks like this:



if we do something like this in setenv.sh, the substitution works great

export DB_USERNAME=xyz
export DB_PASSWORD=vvv

export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"

However, if on a linux box, if someone did a "ps -ef | grep java", they
would be able to see the actual values of these parameters.

theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
-Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
tomcat/apache-tomcat/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-DDB_USERNAME=xyz
-DDB_PASSWORD=vvv

Which our operations team does not want

Is there any syntax that Tomcat can recognize to substitute true
environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
properties injected into the JVM by -D (i.e. export
DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any documentation
on it, but thought would ask.

Thanks in advance,
Al






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

Re: Technology Information Request - Apache Tomcat 7.0

[Rainer Jung]

Hi Pradipto,

the question was answered by Mark Thomas just a few days ago in the 
following mail thread:


https://marc.info/?t=15163382301=1=2

Regards,

Rainer

Am 23.01.2018 um 11:39 schrieb Mukherjee,Pradipto:

Hi,

Greetings of the day!

My name is Pradipto Mukherjee from Gartner Inc.

We in Gartner, deliver technology research to global technology business 
leaders to make informed decisions on key initiatives.

As part of our technology research, we maintain an internal library of various 
IT technologies, wherein we maintain vendor lifecycle information for the 
technologies present in the library.

While working on some Apache's technologies, we were unable to verify the 
Lifecycle Support dates of the technology, Apache Tomcat 7.0 .

We were able to find the obsolete dates of version 6.0 and 8.0 from the link 
below and hence, would appreciate if we could get more information on the 
obsolete/end of life date for version 7.0 of Apache Tomcat.

https://tomcat.apache.org/tomcat-80-eol.html
https://tomcat.apache.org/tomcat-60-eol.html


Thanks,
Pradipto Mukherjee
Research Analyst
CEB is now Gartner
6th Floor, Tower 10-B,
DLF Cyber City, Gurgaon 122002, INDIA
Email: pradipto.mukher...@gartner.com
Direct: +91-1244796316
Web: http://gartner.com/ceb




This e-mail message, including any attachments, is for the sole use of the 
person to whom it has been sent, and may contain information that is 
confidential or legally protected. If you are not the intended recipient or 
have received this message in error, you are not authorized to copy, 
distribute, or otherwise use this message or its attachments. Please notify the 
sender immediately by return e-mail and permanently delete this message and any 
attachments. Gartner makes no warranty that this e-mail is error or virus free.



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

Re: Using Environment variables instead of Java -D properties for context.xml substitution

[Algirdas Veitas]

Thanks for the quick reply George!

We could, but the data is still available, in this case a file, versus in
the output of "ps -ef | grep java".  We can obviously encrypt the sensitive
information.

One idea, in order to support injecting Environment Variables would be to
support a syntax of

${env.DB_USER}

where if the subsitution property starts with "env", then the variable
could be retrieve by System.getEnv(...) otherwise System.getProperty(...).





On Mon, Jan 22, 2018 at 10:19 PM, George Stanchev 
wrote:

> Can you use catalina.properties? From the docs [1]
>
> " All system properties are available including those set using the -D
> syntax, those automatically made available by the JVM and those configured
> in the $CATALINA_BASE/conf/catalina.properties file."
>
> [1] https://tomcat.apache.org/tomcat-7.0-doc/config/index.html
>
>
> -Original Message-
> From: Algirdas Veitas [mailto:apvei...@gmail.com]
> Sent: Monday, January 22, 2018 4:02 PM
> To: users@tomcat.apache.org
> Subject: Using Environment variables instead of Java -D properties for
> context.xml substitution
>
> Hi,
>
> We have a context.xml under $TOMCAT_HOME/conf that looks like this:
>
> auth="Container"
>type="javax.sql.DataSource"
>username="${DB_USERNAME}"
>password="${DB_PASSWORD}"
>driverClassName="oracle.jdbc.OracleDriver"
>validationQuery="select 1 from dual"
>testOnBorrow="true"
>url="${DB_URL}"
> />
>
> if we do something like this in setenv.sh, the substitution works great
>
> export DB_USERNAME=xyz
> export DB_PASSWORD=vvv
>
> export JAVA_OPTS="$JAVA_OPTS -DDB_USERNAME=$DB_USERNAME"
> export JAVA_OPTS="$JAVA_OPTS -DDB_PASSWORD=$DB_PASSWORD"
>
> However, if on a linux box, if someone did a "ps -ef | grep java", they
> would be able to see the actual values of these parameters.
>
> theuser 127734  1  0 Jan19 ?00:04:39 /opt/java/bin/java
> -Djava.util.logging.config.file=/opt/mis/apps/jaspersoft/
> tomcat/apache-tomcat/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -DDB_USERNAME=xyz
> -DDB_PASSWORD=vvv
>
> Which our operations team does not want
>
> Is there any syntax that Tomcat can recognize to substitute true
> environment variables (i.e. export DB_USERNAME=xyz) as opposed to Java
> properties injected into the JVM by -D (i.e. export
> DB_USERNAME=$DB_USERNAME) ?  Haven't been able to find any documentation
> on it, but thought would ask.
>
> Thanks in advance,
> Al
>

Technology Information Request - Apache Tomcat 7.0

[Mukherjee,Pradipto]

Hi,

Greetings of the day!

My name is Pradipto Mukherjee from Gartner Inc.

We in Gartner, deliver technology research to global technology business 
leaders to make informed decisions on key initiatives.

As part of our technology research, we maintain an internal library of various 
IT technologies, wherein we maintain vendor lifecycle information for the 
technologies present in the library.

While working on some Apache's technologies, we were unable to verify the 
Lifecycle Support dates of the technology, Apache Tomcat 7.0 .

We were able to find the obsolete dates of version 6.0 and 8.0 from the link 
below and hence, would appreciate if we could get more information on the 
obsolete/end of life date for version 7.0 of Apache Tomcat.

https://tomcat.apache.org/tomcat-80-eol.html
https://tomcat.apache.org/tomcat-60-eol.html


Thanks,
Pradipto Mukherjee
Research Analyst
CEB is now Gartner
6th Floor, Tower 10-B,
DLF Cyber City, Gurgaon 122002, INDIA
Email: pradipto.mukher...@gartner.com
Direct: +91-1244796316
Web: http://gartner.com/ceb




This e-mail message, including any attachments, is for the sole use of the 
person to whom it has been sent, and may contain information that is 
confidential or legally protected. If you are not the intended recipient or 
have received this message in error, you are not authorized to copy, 
distribute, or otherwise use this message or its attachments. Please notify the 
sender immediately by return e-mail and permanently delete this message and any 
attachments. Gartner makes no warranty that this e-mail is error or virus free.

A question about The Relationship between Http Session and WebSocket Session

[tong__hui]

Hello, 
I'm a J2EE Programmer use Tomcat deploy my webapplication.
I have a question about the relationship between Http Session and WebSocket 
Session in tomcat.
Is  Http Session contains WebSocket Session? or they are seperate.

Please help me!

Thank you very much!

Server version: Apache Tomcat/7.0.81
Server built:   Aug 11 2017 10:21:27 UTC
Server number:  7.0.81.0
OS Name:Linux
OS Version: 2.6.32-504.el6.x86_64
Architecture:   amd64
JVM Version:1.8.0_25-b17
JVM Vendor: Oracle Corporation