Re: Undefined behaviour with Credential Handler

[Sreyan Chakravarty]

Yes but that requires implementing your own credential handler. But the
default one will still have the bug. Right now I am thinking of using an
authentication framework like Apache Shiro.

On Thu, Sep 10, 2015 at 1:48 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sryan,
>
> On 9/9/15 12:50 PM, Sreyan Chakravarty wrote:
> > Well I guess now its confirmed that it is a bug. Do you still need
> > the code ?
>
> No, I don't think I will.
>
> However, since you wrote your own CredentialHandler, you could merely
> patch it to check in the matches() method for null. Something like this:
>
> @Override
> public boolean matches(String inputCredentials,
>String storedCredentials) {
> if(null == storedCredentials)
> return false;
>
> return matchesSaltIterationsEncoded(inputCredentials,
> storedCredentials);
> }
>
> Then you can resume your testing.
>
> - -chris
>
> > On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > Sreyan,
> >
> > On 9/8/15 6:31 AM, Sreyan Chakravarty wrote:
>  Okay is if I have stored my password in my DB with SHA256
>  encryption, can the credential handler declared in the realm
>  work if the it is declared with SHA512 ?
> >
> > No. SHA256 and SHA512 produce hashes of different sizes, so with
> > the same input, they will always produce different outputs.
> >
> > https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
> >
>  As far as I know it must be same algorithm, salt and
>  iterations for the hash to be matched perfectly.
> >
> > Correct.
> >
>  Now take my case-:
> 
>    "org.apache.catalina.realm.SecretKeyCredentialHandler"
>  algorithm = "PBEWITHMD5ANDTRIPLEDES" />
> 
>  Okay this my credential handler that I am using. In my DB
>  the password is stored using PBEWITHHMACSHA384ANDAES_256. A
>  completely different algorithm that the one specified before.
>  So how come when I put in my user-id and password on my
>  form-login page I am not getting an authentication error
>  instead I am being forwarded to the protected resource.
> >
> > Perhaps PBEWITHMD5ANDTRIPLEDES and PBEWITHHMACSHA384ANDAES_256 are
> > somehow aliases of each other? Also, it's possible that your
> > implementation of the algorithm is flawed.
> >
> > Try running the "mutate" method from a command-line driver on some
> > sample input to see what falls out.
> >
>  It should use the algorithm in the CredentialHandler to
>  mutate the password. Now don't tell me that two different
>  algorithms offer the same hash.
> 
>  What is going on here ?
> >
> > My guess is a bug in the CredentialHandler itself. Can you post
> > some cod e?
> >
> > -chris
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8JQpAAoJEBzwKT+lPKRYBlQP/2dedJFcZSsAGF+0uxRGIPfr
> vW26AOOaT/qPS88eQiCucufYOpPx180ifdIdnNVtLRZbIYyeQMBQiFTezMZM1Psx
> 2Ufuw1ZEPV0kZteptnDgGyipZKtDaxl/7hYY76O3yy8ki62Fa6TcRtR8UBPY0pJs
> kVYw9ZWqVVq8smkDomYAA/wwtGUzXORB3RN5yKGtKPx7roV00cLAoKQTv4ZlxfM5
> LMuuorMx9jnWI9JXTlQdxi9ydQ1IlALrv9igbXE1/cYCnLrHtJVrE+bzvL4XPy+1
> C9H8UdWT8Mqdn4qSIi5Zp0JDkRffvjVj4WA7V3Yt2+7HqlcZjEFDdAtN//DJ9T4A
> Zc/NJ73vXyEnFKt1S3mgqTIaGi7tr13VX8mXyFVSXzP/wvoQpCaOr0RYyIVvTdOc
> r42X1j5gq3tKTV1Hxe73SoM9iJivFvq6VFq+zvzv3fdNyHt1TukwM3E7nxnd6cXr
> euWj5IUc1+Z002xQBPKWjxAJFxsmd1cvM9A4zuhr70P2WcTsYSCbTn0ETB7Vtssb
> Rr1ED6jf2MKE/JIU8G6YKU5yuLqAnSaJleHOyWz/N8X5fUN5q4sfeV174UluS1WU
> +J017q60ZBrkEdzPB7bO/Jku1ThPHcFMbg5VfQQ+TTyN6AugQYfvasrvfBhu2wdL
> 3CMQ6Hf+ShnIB8aWI8zj
> =Sxyr
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Firefox SSL with APR - losing client certificate

[David Balažic]

Reported as Bug 58244 - two way SSL loses client certificate after a few 
requests

https://bz.apache.org/bugzilla/show_bug.cgi?id=58244


David Balažic

> -Original Message-
> From: David Balažic
> Sent: 7. August 2015 17:38
> To: users@tomcat.apache.org
> Subject: Firefox SSL with APR - losing client certificate
> Importance: Low
> 
> Hi!
> 
> I use tomcat 6.0.44 wit APR on Windows x64.
> I set up SSLVerifyClient="optional" and since then encounter the following
> problem with Firefox 39.0.03 (IE works OK):
> 
> On first access Firefox shows the client certificate selection dialog. I 
> select a
> certificate and continue. The web application "sees" the selected certificate
> and show a proper response page.
> But on next access (I click a link) the client certificate is not visible to 
> the
> application any more. It gets null from the method call
> HttpServletRequest.getAttribute("javax.servlet.request.X509Certificate")
> 
> Goggole found https://bz.apache.org/bugzilla/show_bug.cgi?id=37869
> (similar)
> And http://grokbase.com/t/tomcat/users/102pdv412y " [Tomcat-users]
> Client certificate gone after 1 minute timeout (SSL, APR)"
> (even more similar, except for me it fails on next access without a minute of
> waiting)
> As suggested in the second link, clearing cache and authentication in the
> browser is a workaround that works. Kind of as one has to select the
> certificate again and do it before every click on a link.
> 
> Strange, just now it worked fine for a few minutes.
> 
> Is this some known issue?
> 
> Without APR, using JSSE, it works fine (and did so for years).
> 
> This started after upgrading yesterday tomcat from 6.0.35_x64 (no APR) to
> apache-tomcat-6.0.44-windows-x64.zip (with or without APR).
> I start tomcat from Eclipse, using JRE 1.6.0_45  (each 64 bit version).
> 
> Firefox version 39.0, today updated to 39.0.3
> 
> The Connector line from server.xml:
> 
>SSLCertificateFile="C:/key_public.pem"
>   SSLCertificateKeyFile="C:/key_private.pem"
>   SSLEnabled="true" SSLPassword="changeit"
> SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
>   SSLVerifyClient="optional" URIEncoding="UTF-8" maxThreads="150"
> port="8443"
>   protocol="org.apache.coyote.http11.Http11AprProtocol"
> scheme="https"
>   secure="true" />
> 
> 
> Regards,
> David Balažic
> 
> -
> 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

cluster isn't deploying apps to all members

[Martijn Bos]

Hi all,

I think I "solved" it myself.

My problem was that when I deployed a webaap on one of the
cluster-members it didn't get deployed on the other member.
I did this with the manager web-application.

However when I drop a war-file in the watchDir of the farmWarDeployer it
gets deployed to the other member. (Apperantly by memory or so. Since I
do not see the war file appearing on in the tmpDir, deployDir or
watchDir on the other cluster member)

Can somone confirm that deploying through the manager-webapp will not
deploy to all the cluster members? Otherwise there is still something
wrong with my setup.

btw. I see that the farmWarDeployer is not completely stable. A few
times I noticed that the app is not deployed on the other member, trying
one more time, and it does succeed.

Anyway...thanks for listening,

Best regards,
Martijn



On 08-09-15 13:28, Martijn Bos wrote:
> Hi all,
> 
> I tried to create a cluster two hosts. At which I did not succeeded
> completely.
> 
> OS(both systems):
> SMP Debian 3.16.7
> 
> java (both systems):
> martijn@bloemkool:~/apache-tomcat-8.0.26/conf$ java -version
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> 
> Tomcat (both systems):
> Apache Tomcat/8.0.26
> 
> I installed 2 tomcat's
> One on host bloemkool.bos.
> The server.xml:
> -
> 
> 
> 
>   
>SSLEngine="on" />
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
> 
>   
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
> 
>   
>  redirectPort="8443" />
>  jvmRoute="bloemkoolRoute">
>   
>  resourceName="UserDatabase"/>
>   
>autoDeploy="true">
>channelSendOptions="8">
>  expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
>className="org.apache.catalina.tribes.group.GroupChannel">
>  className="org.apache.catalina.tribes.membership.McastService"
> address="228.0.0.4"
> port="45564"
> frequency="500"
> dropTime="3000"/>
>  className="org.apache.catalina.tribes.transport.nio.NioReceiver"
>   address="192.168.2.123"
>   port="4000"
>   autoBind="100"
>   selectorTimeout="5000"
>   maxThreads="6"/>
>  className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
>className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
> 
>  className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
>  className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
> 
>   
>filter=""/>
>className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
>className="org.apache.catalina.ha.deploy.FarmWarDeployer"
> tempDir="/tmp/war-temp/"
> deployDir="${catalina.base}/webapps"
> watchDir="/tmp/war-listen/"
> watchEnabled="true"/>
>className="org.apache.catalina.ha.session.ClusterSessionListener"/>
> 
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>   
> 
>   
> 
> -
> 
> And one on broccoli.bos.
> The server.xml:
> -
> 
> 
>   
>SSLEngine="on" />
>className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
>className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
>className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
> 
>   
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
>   
>   
>  redirectPort="8443" />
>  jvmRoute="broccoliRoute">
>   
>  resourceName="UserDatabase"/>
>   
>autoDeploy="true">
>  channelSendOptions="8">
>className="org.apache.catalina.ha.session.DeltaManager"
> expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
>  

Re: DNS is hijacked and some filty AD is added at the bottom of our webpage

[George Sexton]

On 9/9/2015 8:46 AM, shi wrote:

Hi gurus,

We have a website running at a tomcat. Its web pages looks good.

Recently, we, however, find some of web pages contain the filthy AD at the 
bottom of the page.

Here are the ways this could be happening:

1. Your server is compromised and it's your server that's inserting the
   ads.
2. Your client is compromised by a virus and it's inserting the ad.
3. Your internet service provider is evil and inserting ads.
4. You are suffering from hijacked DNS on your network. I've seen this
   where the router at the site had been hacked and was passing out DNS
   entries for a server in Russia.
5. Someone's actually compromised your DNS records at the registrar.


The 1st step to figuring out what's going wrong is to get a known clean 
client on a known clean network and see what the page looks like. If 
it's good, then you eliminate 1,2,3, and 4.


to test number 5 use any of the DNS lookup tools on the internet and 
check your domain.


To check number 4, look at the IP addresses of the DNS servers being 
handed out by your DHCP server.




We really could not understand why there are these filthy AD at the web page. 
We make sure the web page doesn't contain any ADs at tomcat.
But when we access these webpage via internet, we find these filthy AD added..

We search related knowledge and find it looks like some DNS is hijacked. It 
causes when the client is accessing the website, the hijacked DNS will be used 
to translate the webname to  its IP. During this process, the hijacked DNS adds 
the filthy AD at the web page.

So my current question is:
how to avoid/resolve this issue at java server side? Are there many good 
solutions to resolve it?


Thanks,
Shi


--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com

Re: Undefined behaviour with Credential Handler

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/10/15 8:10 AM, Sreyan Chakravarty wrote:
> Yes but that requires implementing your own credential handler.

Sorry, I thought you had implemented your own credential handler.

> But the default one will still have the bug.

Oh, I was just suggesting that fix as something temporary until an
updated version of Tomcat is released where this bug is fixed. The fix
is trivial, so I have no doubt it will be in the next release.

> Right now I am thinking of using an authentication framework like
> Apache Shiro.

Feel free to do that. You'll have to implement a lot of plumbing code
yourself to use Apache Shiro. (It seems like Tomcat ought to support
Shiro, eh? Maybe we should get together with them to build an
out-of-the-box configurable component in Tomcat).

- -chris

> On 9/9/15 12:50 PM, Sreyan Chakravarty wrote:
 Well I guess now its confirmed that it is a bug. Do you still
 need the code ?
> 
> No, I don't think I will.
> 
> However, since you wrote your own CredentialHandler, you could
> merely patch it to check in the matches() method for null.
> Something like this:
> 
> @Override public boolean matches(String inputCredentials, String
> storedCredentials) { if(null == storedCredentials) return false;
> 
> return matchesSaltIterationsEncoded(inputCredentials, 
> storedCredentials); }
> 
> Then you can resume your testing.
> 
> -chris
> 
 On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz < 
 ch...@christopherschultz.net> wrote:
 
 Sreyan,
 
 On 9/8/15 6:31 AM, Sreyan Chakravarty wrote:
>>> Okay is if I have stored my password in my DB with
>>> SHA256 encryption, can the credential handler declared
>>> in the realm work if the it is declared with SHA512 ?
 
 No. SHA256 and SHA512 produce hashes of different sizes, so
 with the same input, they will always produce different
 outputs.
 
 https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions

>>>
 
As far as I know it must be same algorithm, salt and
>>> iterations for the hash to be matched perfectly.
 
 Correct.
 
>>> Now take my case-:
>>> 
>>> >> "org.apache.catalina.realm.SecretKeyCredentialHandler" 
>>> algorithm = "PBEWITHMD5ANDTRIPLEDES" />
>>> 
>>> Okay this my credential handler that I am using. In my
>>> DB the password is stored using
>>> PBEWITHHMACSHA384ANDAES_256. A completely different
>>> algorithm that the one specified before. So how come
>>> when I put in my user-id and password on my form-login
>>> page I am not getting an authentication error instead I
>>> am being forwarded to the protected resource.
 
 Perhaps PBEWITHMD5ANDTRIPLEDES and
 PBEWITHHMACSHA384ANDAES_256 are somehow aliases of each
 other? Also, it's possible that your implementation of the
 algorithm is flawed.
 
 Try running the "mutate" method from a command-line driver on
 some sample input to see what falls out.
 
>>> It should use the algorithm in the CredentialHandler
>>> to mutate the password. Now don't tell me that two
>>> different algorithms offer the same hash.
>>> 
>>> What is going on here ?
 
 My guess is a bug in the CredentialHandler itself. Can you
 post some cod e?
 
 -chris
> 
> --
- ---
>
>
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
> 
> 
 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8aXyAAoJEBzwKT+lPKRYav4P/jogPWNaIJLqlX8tFLMvE4th
78dDP553/snHIZ+/g27ZyD2P3yIAcD1MURgO1B8k0GDJrbxQdLrtvW8jNt1J8UN8
M0Wa68PrWxyy8uFecOhvHDwBd749teNl5Z/EimlzooC4FY5cFWCUgsY4qRAfd3/r
aApCpSkNKOGGcJJ1RQuUYRski72H6OezzhSZthbgr+9YYtDtpxpkeJ2UikWfzeFc
1sl5B1wbjAl/Da8YU1tM5SNgCHLR5MAA2WDJlTyHHQrG42lhp8aE5FHVs62xT/VD
1v4tJP1mFNc709tKpd+hnvCczjMd4BaPP2rKmaEozhuGPyfNpPcGP1xQAmBIvWR9
0RaEk1UhpwQdaS1kxOqBHLYLmplhmt9BS4AFy7WUcWZfiEGqi9IvG3Oblt2OinRb
68b4fQbgiW4NBBccw1yFYQ8XAQCxtB340b8j7y8OiMWihgWtxtmpNrazW0AoHgV/
QcYlhQ8fldwa5ysbefvZC82eQJ0s0ivvsX7iclNCJHOUW48oud9nscHu9r+3pBm3
s3bbpnXGrFFNwZpSGmvlQ7im0Ozv+huuqe7vg3pGryWxte5+I54m8y7xkQs0mTZF
tGjYDk20qn30j/Oke5AO99fVzpgJl9jlBVY+CrPTKKm3GzEj8cBl92jnN8flzjZP
fwwURalFrQjt3tbqNUvW
=JROa
-END PGP SIGNATURE-

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

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/9/15 9:43 PM, Pottinger, Hardy J. wrote:
> It doesn't matter which Authenticator is installed, they all behave
> the same way. The user name from httpd is used to populate the
> remote user name and the user principal and the user principal
> being set is what bypasses most of the authentication code.
> 
> All of the authenticators will cache the Principal in the session
> if one exists but none of them (apart from FORM) should ever create
> one.
> 
> The authenticator you will get will depend on whatever is in
> web.xml.

So, it looks like there is no auth-type specified in web.xml, so what
does the app get? It looks like *something* is in there, given the
stack trace provided.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8aQbAAoJEBzwKT+lPKRY5oIQAIoGHHBsxESORGC/Nsaa5O5O
8I2SL6iHcmjw8d8SE8pVGuY6B4W0w49LMy2px3bar5Z8NMwrWGDwj9s01H0+lN6b
f7ZtmZsfLTFGmlpOqkpcHqhSsedO8NqEIO3/e84nwKKtbOQFdragJ48qkJ/oYk4w
/PMjAosH2kE/egwXHg2dGzy5WCox91CI2f/4JZjXlsrZikEErMdqS9zoYAUt7tlD
JFUrcSey9T0V0JfoqSv0CTV2kRtI/B2LcOuh5eQqyUks2mQvb08BKPoGp1PM4DjK
1sX7IpTUurc8eGsDSBSd/wciUU47bhPmK1YmyN3EwqxIGsN82C2EVe+t/N3gFhoe
PiUtofF3nwOCfSHPUiiNnTpHYIetgNUpCkdbmnwgV1dEvWTyWCCMWvIoPAztozkO
zIz2Qr6K5Lyy2no5+zPpOdipeMlZ5rXvEXBDFGpmtmlAKwphcz1/SxNV+YDgqmnT
KHcorZ/oltH/qyAPWZeu8/Hu6tQgb9Ua8kAayE0sK38grXI7kJHNlQyPldxYZjKB
TG2IGQd46XyJKSt6nA53hmbMPFhIwPl2MvgLzQ5j7lrlO64TCaCRtQwi9pCjRGHL
d/BWRVPXEABRdIKoxG/beFRaob/h4TkIvcOChqUe+lHJ+/3NGjQLmhVSFYseCFbK
eyK7kji4cGdJF5iH3Ayn
=J6nA
-END PGP SIGNATURE-

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

Re: cluster isn't deploying apps to all members

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martijn,

On 9/10/15 7:39 AM, Martijn Bos wrote:
> I think I "solved" it myself.
> 
> My problem was that when I deployed a webaap on one of the 
> cluster-members it didn't get deployed on the other member. I did
> this with the manager web-application.
> 
> However when I drop a war-file in the watchDir of the
> farmWarDeployer it gets deployed to the other member. (Apperantly
> by memory or so. Since I do not see the war file appearing on in
> the tmpDir, deployDir or watchDir on the other cluster member)
> 
> Can somone confirm that deploying through the manager-webapp will
> not deploy to all the cluster members? Otherwise there is still
> something wrong with my setup.

Yes, the manager web application has no knowledge of the existence of
the cluster. You need to use FarmWebDeployer if you want to push the
WAR file to multiple cluster members.

> btw. I see that the farmWarDeployer is not completely stable. A
> few times I noticed that the app is not deployed on the other
> member, trying one more time, and it does succeed.

I believe the FWD doesn't get a huge amount of use in the wild. If
you're willing to instrument the FWD and make suggestions for
improvement, I'm sure we can get any bugs worked-out.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8aUJAAoJEBzwKT+lPKRYUCgQAJmAdw8MzM0xm2JUq6u88Jba
Nj4esd6KqFPkAHl5jAlQfUoGKVq3a4oYCdqocNtzPHpiTysgRUT0/wWDwnK7TJVN
t2XgQnfKbMGzx7dUJBGk+fGJw72G10kynz4PNZ7KgHnz8oRMr82HRAkurZVfxQq/
h7wcfxZRIn0Juu39NBx8LHWTvDeym6l128VtoN0+C0OGEGcWKNmOtN1BZKXj/H4D
9mkF6XGbHWWZ2ZFVt1r+IPntWAE4dvE1R0m3RbVrW3qbjXqnEjqZn+21XuoCK/OP
Lc7WMXfacGO7Ay8Qg6Dvfal9ngTuZ3bUcTlADatzbxl8sFpD7eLgz42skCYFWG6Y
lWNB4XwzYArn4Lyjf/A3Ib5OFcL4bayPdPnLfJMcQXoxO+m5dmTfs6WDHdoGYyyc
QarOcPiy9YecxKTyjqqPRjSEdg4Bj6UXrFUU4NNdulzFnA9y4EDM3eILFHdIbe55
QbgvTSa4BsF5L9kc1PWaXlj/VTQ+mYcj1bcTmcwV0APjVAPZbnUVSPNI5ewNAyBE
8idaO+/+pPtJVRYasOosIYU731uYrysFmGuEvFeRiBAS3APNBKv1knTrrdZqsvRM
Ep/tzI7woPc6a9W3lO1nnGo0xe/XmxnJJUcO2crgARfPbJPLk2g3VCQotitVVGY8
tob8vwVzYwaisaTuIXxh
=czB+
-END PGP SIGNATURE-

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

RE: Multiple JSESSIONID cookies being presented.

[Jeffrey Janner]

> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, September 09, 2015 1:50 PM
> To: Tomcat Users List 
> Subject: Re: Multiple JSESSIONID cookies being presented.
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Jeffrey,
> 
> On 9/9/15 12:08 PM, Jeffrey Janner wrote:
> >> -Original Message- From: Caldarale, Charles R
> >> [mailto:chuck.caldar...@unisys.com] Sent: Tuesday, September 08,
> >> 2015 4:58 PM To: Tomcat Users List 
> >> Subject: RE: Multiple JSESSIONID cookies being presented.
> >>
> >>> From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> >>> Subject: Re: Multiple JSESSIONID cookies being presented.
> >>
>  Thanks for the clarification of what's supposed to happen on
> >> receipt, Jose.
>  However, I am describing what happens on first contact from
>  the
> >> client to the server.
>  The browser sends https://hostname/APP2, and Tomcat returns:
>  JSESSIONID=, path=/and   JSESSIONID=,
>  path=/APP2/
> >>
> >>> Indeed, it doesn't make sense for me to return different id (
> >>>  ,  ) if you are accesing to only one context (/APP2)
> >>
> >>> Are you sure that your webapp deployed in /APP2 is not accesing
> >>> to resources ( session-aware resources as JSP, servlet, .. .I
> >>> mean) stored in ROOT context ?
> >>
> >> As I think someone previously mentioned, the client (browser) may
> >> well be sending an unsolicited request to the default webapp,
> >> such as when trying to retrieve favicon.ico.  You might want to
> >> run Fiddler or Wireshark on the client to see exactly what's
> >> being sent to the server.
> >>
> >
> > And there's no way to keep a browser from asking for the
> > favicon.ico file from the root. We don't have one, so I would
> > expect a 404 is sent, which looking at the access log file is what
> > happens. However, is this the issue?  I tested this doing a manual
> > https://hostname/favicon.ico and see that we also return our root
> > app's error page. We also seem to be doing that for the
> > auto-generated request, judging by the bytes returned value, even
> > though it won't get displayed. And I bet that the error page is
> > setting the session cookie for some reason. Does that sound
> > reasonable? Is my solution just providing a favicon.ico file?
> 
> Can you make sure that all cookies have been cleared from the test
> client and then explain exactly when Tomcat sends the Set-Cookie headers
> ?
> 
> When we had this problem, it was usually because the client had old
> funky session ids in its cookie jar and the solution was to blow them
> all away and start-over fresh. (Then fix our software so it wouldn't
> happen anymore.)
> 
> - -chris
Thanks for all the help guys. I think I've sussed out what is going on here.  
Now just have to get the Dev guys to address it.
After spending a good bit of time clearing and watching cookies and access 
logs, both with and without a favicon.ico file, I found that the doubling was 
happening only if the file was missing.  I checked the error.jsp file and it 
does have session=true set, and if the icon file is missing, the error.jsp is 
definitely being sent.
So it looks like the possible solutions are:
1) provide a favicon.ico file.
2) remove the session=true setting from the error page.
3) somehow not send the error.jsp when a sub-link (image, script, etc.) results 
in a 404.
4) Have the login page of APP2 provide it's own icon  directive (it 
doesn't currently have one.)

Any other options?
Jeff

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

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

Hi, in helping a colleague diagnose another problem for another servlet, I was 
using PsiProbe, and I noticed that it has session diagnostics. Doh! I promptly 
fired up PsiProbe on my Tomcat server, returning to this JSESSIONID issue, and 
watched the session get created as part of a password challenge page, and one 
thing jumped out at me: The session attribute we are creating to hold the flag 
to indicate the session is "interrupted"... is not serializable... which I 
think means that, when the new session is created as part of session fixation 
protection, the "interrupted" flag won't transfer to the new session.

So... I *think* what I might need to do is set a maker for our request class 
that it implements Serializable.
http://stackoverflow.com/questions/763/how-do-i-make-the-session-data-serializable

I'll let you know if this works out.

--Hardy

From: Christopher Schultz [ch...@christopherschultz.net]
Sent: Thursday, September 10, 2015 10:39 AM
To: Tomcat Users List
Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/9/15 9:43 PM, Pottinger, Hardy J. wrote:
> It doesn't matter which Authenticator is installed, they all behave
> the same way. The user name from httpd is used to populate the
> remote user name and the user principal and the user principal
> being set is what bypasses most of the authentication code.
>
> All of the authenticators will cache the Principal in the session
> if one exists but none of them (apart from FORM) should ever create
> one.
>
> The authenticator you will get will depend on whatever is in
> web.xml.

So, it looks like there is no auth-type specified in web.xml, so what
does the app get? It looks like *something* is in there, given the
stack trace provided.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8aQbAAoJEBzwKT+lPKRY5oIQAIoGHHBsxESORGC/Nsaa5O5O
8I2SL6iHcmjw8d8SE8pVGuY6B4W0w49LMy2px3bar5Z8NMwrWGDwj9s01H0+lN6b
f7ZtmZsfLTFGmlpOqkpcHqhSsedO8NqEIO3/e84nwKKtbOQFdragJ48qkJ/oYk4w
/PMjAosH2kE/egwXHg2dGzy5WCox91CI2f/4JZjXlsrZikEErMdqS9zoYAUt7tlD
JFUrcSey9T0V0JfoqSv0CTV2kRtI/B2LcOuh5eQqyUks2mQvb08BKPoGp1PM4DjK
1sX7IpTUurc8eGsDSBSd/wciUU47bhPmK1YmyN3EwqxIGsN82C2EVe+t/N3gFhoe
PiUtofF3nwOCfSHPUiiNnTpHYIetgNUpCkdbmnwgV1dEvWTyWCCMWvIoPAztozkO
zIz2Qr6K5Lyy2no5+zPpOdipeMlZ5rXvEXBDFGpmtmlAKwphcz1/SxNV+YDgqmnT
KHcorZ/oltH/qyAPWZeu8/Hu6tQgb9Ua8kAayE0sK38grXI7kJHNlQyPldxYZjKB
TG2IGQd46XyJKSt6nA53hmbMPFhIwPl2MvgLzQ5j7lrlO64TCaCRtQwi9pCjRGHL
d/BWRVPXEABRdIKoxG/beFRaob/h4TkIvcOChqUe+lHJ+/3NGjQLmhVSFYseCFbK
eyK7kji4cGdJF5iH3Ayn
=J6nA
-END PGP SIGNATURE-

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


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

RE: Multiple JSESSIONID cookies being presented.

[Caldarale, Charles R]

> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] 
> Subject: RE: Multiple JSESSIONID cookies being presented.

> I checked the error.jsp file and it does have session=true set, and if the 
> icon file 
> is missing, the error.jsp is definitely being sent.

> So it looks like the possible solutions are:
> 1) provide a favicon.ico file.
> 2) remove the session=true setting from the error page.
> 3) somehow not send the error.jsp when a sub-link (image, script, etc.) 
> results in a 404.
> 4) Have the login page of APP2 provide it's own icon  directive (it 
> doesn't currently 
> have one.)

Why would you ever want your error.jsp to create a session?  Sounds like an 
easy DoS attack to me.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: cluster isn't deploying apps to all members

[Martijn Bos]

On 10-09-15 17:43, Christopher Schultz wrote:
> Martijn,
> 
> On 9/10/15 7:39 AM, Martijn Bos wrote:
>> I think I "solved" it myself.
> 
>> My problem was that when I deployed a webaap on one of the 
>> cluster-members it didn't get deployed on the other member. I did
>> this with the manager web-application.
> 
>> However when I drop a war-file in the watchDir of the
>> farmWarDeployer it gets deployed to the other member. (Apperantly
>> by memory or so. Since I do not see the war file appearing on in
>> the tmpDir, deployDir or watchDir on the other cluster member)
> 
>> Can somone confirm that deploying through the manager-webapp will
>> not deploy to all the cluster members? Otherwise there is still
>> something wrong with my setup.
> 
> Yes, the manager web application has no knowledge of the existence of
> the cluster. You need to use FarmWebDeployer if you want to push the
> WAR file to multiple cluster members.
> 

Ah great. Then I'm not going insane afterall:-)


>> btw. I see that the farmWarDeployer is not completely stable. A
>> few times I noticed that the app is not deployed on the other
>> member, trying one more time, and it does succeed.
> 
> I believe the FWD doesn't get a huge amount of use in the wild. If
> you're willing to instrument the FWD and make suggestions for
> improvement, I'm sure we can get any bugs worked-out.
> 

That is actually very tempting. However my JAVA skills are moderate at
best, so I'm not to sure whether I should proceed in that direction.
On the other hand it doesn't hurt to have a look at the code, and
see what I can do.

Best Regards,
Martijn


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



signature.asc
Description: OpenPGP digital signature

Intermittent failure while deploying war file on Tomcat 8.0.24

[prashant gothi]

Tomcat version: 8.0.24
OS RHEL 6.6


Just one war file (ascws.war) is deployed under it. We are seeing
intermittent failure while deploying war file, tomcat logs indicates (zip
file is empty) exception is mentioned below.

We have verified file is correct (non zero), and only way to recover from
error is manually delete ascws folder (from webapp folder) and restart
tomcat.

FYI.. ascws.war is a symbolic link to other location.

ascws is a spring boot based application.

We are not able to figure out what is wrong, any help is much appreciated.

==
10-Sep-2015 09:47:32.488 INFO [localhost-startStop-1]
org.apache.catalina.startup.HostConfig.deployWAR Deploying web application
archive /opt/apache-tomcat/webapps/ascws.war
10-Sep-2015 09:47:32.628 SEVERE [localhost-startStop-1]
org.apache.catalina.core.ContainerBase.addChildInternal
ContainerBase.addChild: start:
 org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ascws]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:725)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.catalina.LifecycleException: Failed to start
component [org.apache.catalina.webresources.StandardRoot@1690212]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at
org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:4845)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4975)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 10 more
Caused by: org.apache.catalina.LifecycleException: Failed to initialize
component [org.apache.catalina.webresources.JarResourceSet@5dd3221b]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:139)
at
org.apache.catalina.webresources.StandardRoot.startInternal(StandardRoot.java:699)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 13 more
Caused by: java.lang.IllegalArgumentException: java.util.zip.ZipException:
zip file is empty
at
org.apache.catalina.webresources.JarResourceSet.initInternal(JarResourceSet.java:96)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
... 16 more
Caused by: java.util.zip.ZipException: zip file is empty
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(Unknown Source)
at java.util.zip.ZipFile.(Unknown Source)
at java.util.jar.JarFile.(Unknown Source)
at java.util.jar.JarFile.(Unknown Source)
at
org.apache.catalina.webresources.JarResourceSet.initInternal(JarResourceSet.java:88)
... 17 more

10-Sep-2015 09:47:32.630 SEVERE [localhost-startStop-1]
org.apache.catalina.startup.HostConfig.deployWAR Error deploying web
application archive /opt/apache-tomcat/webapps/ascws.war
 java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/ascws]]
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:729)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:701)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:717)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:945)
at
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1768)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

10-Sep-2015 09:47:32.631 INFO [localhost-startStop-1]
org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
application archive /opt/apache-tomcat/webapps/ascws.war has finished in
142 ms



==




Regards,
Prashant

Re: [somewhat OT] Undefined behaviour with Credential Handler

[tomcat]

Hi.

I have been following this thread loosely, and I have nothing about Tomcat authentication 
per se, but maybe now may be the moment to suggest another approach : why not use an 
Apache httpd as a front-end to Apache Tomcat, do the user authentication/authorization at 
the Apache httpd level (in almost whatever flavor known to man, and generally dictated by 
the customer circumstances more than by anything else), and pass to Tomcat requests which 
are already authenticated/authorized ?


Apache httpd having been on the market a bit longer than Tomcat, and having a 
comparatively higher "market share" in terms of number of webserver installations, it has 
already acquired over time a very wide range of user authentication mechanisms, which 
Tomcat doesn't match yet, and will probably never match unless a lot of developer time is 
spent at just that aspect (never mind the developer time that has already been spent at 
it).  Developer time which could probably be fruitfully spent at other more Tomcat- and 
Java-servlet-centric issues, rather than at duplicating what is already solved and heavily 
tested elsewhere.


Installing and configuring Apache httpd as a front-end to Tomcat is fairly easy, fairly 
efficient in operation, and fairly frequent for real-world Tomcat sites, even if not 
always for authentication purposes per se.
Adding user authentication/authorization to such a setup is almost trivial from an httpd 
point of view, and totally trivial from the Tomcat point of view (well, at least with AJP).


And, it would stay in the big Apache free and open-source family.

Re: https://en.wikipedia.org/wiki/Law_of_the_instrument
and https://en.wikipedia.org/wiki/Overengineering

I mean, from a human point of view, I understand the temptation for a Java developer, and 
for a Tomcat Java developer, to do everything in Java and in Tomcat rather than 
somewhere/somehow else.  And I do recognise that in some use cases, one can not do 
otherwise.  But at some point, the more bells and whistles you add to something, the 
heavier it becomes and the more resources are needed to develop, debug, document and 
maintain all that stuff. Isn't it so ?




On 10.09.2015 21:49, Sreyan Chakravarty wrote:

"Feel free to do that. You'll have to implement a lot of plumbing code
yourself to use Apache Shiro. (It seems like Tomcat ought to support
Shiro, eh? Maybe we should get together with them to build an
out-of-the-box configurable component in Tomcat)."

Well I don't know that but you people could try making Tomcat Container
managed security easier to use.

On Thu, Sep 10, 2015 at 9:16 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/10/15 8:10 AM, Sreyan Chakravarty wrote:

Yes but that requires implementing your own credential handler.


Sorry, I thought you had implemented your own credential handler.


But the default one will still have the bug.


Oh, I was just suggesting that fix as something temporary until an
updated version of Tomcat is released where this bug is fixed. The fix
is trivial, so I have no doubt it will be in the next release.


Right now I am thinking of using an authentication framework like
Apache Shiro.


Feel free to do that. You'll have to implement a lot of plumbing code
yourself to use Apache Shiro. (It seems like Tomcat ought to support
Shiro, eh? Maybe we should get together with them to build an
out-of-the-box configurable component in Tomcat).

- -chris


On 9/9/15 12:50 PM, Sreyan Chakravarty wrote:

Well I guess now its confirmed that it is a bug. Do you still
need the code ?


No, I don't think I will.

However, since you wrote your own CredentialHandler, you could
merely patch it to check in the matches() method for null.
Something like this:

@Override public boolean matches(String inputCredentials, String
storedCredentials) { if(null == storedCredentials) return false;

return matchesSaltIterationsEncoded(inputCredentials,
storedCredentials); }

Then you can resume your testing.

-chris


On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

Sreyan,

On 9/8/15 6:31 AM, Sreyan Chakravarty wrote:

Okay is if I have stored my password in my DB with
SHA256 encryption, can the credential handler declared
in the realm work if the it is declared with SHA512 ?


No. SHA256 and SHA512 produce hashes of different sizes, so
with the same input, they will always produce different
outputs.

https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions






As far as I know it must be same algorithm, salt and

iterations for the hash to be matched perfectly.


Correct.


Now take my case-:



Okay this my credential handler that I am using. In my
DB the password is stored using
PBEWITHHMACSHA384ANDAES_256. A completely different
algorithm that the one specified before. So how come
when I put in my user-id and password on my form-login
page I am not getting an authentication 

How to Upgrade Java JDK 7 to JDK8 with Keystore SSL Certificate in Tomcat 7

[Ignacio Barragan]

I have Tomcat 7.0.42 on a Windows 2008R2 server.  I’m pretty new to Tomcat.



It uses Java JDK and is configured with a standard JSSE SSL certificate.
How do I upgrade Java on an existing Tomcat server?  All the documentation
is for configuring new installations.



I can repeat the whole installation routine and install JDK in a new
directory and go through the whole thing….create keystore, request new
certificate etc. but that then I would have two certificates for the same
machine?



Keytool has an export command, is that what this is for?  If anyone has
experience in this and can guide me on the best pseudo code method to
upgrade Java using keystore SSL on an existing Tomcat 7 server, that would
be great.





The same issue goes for upgrading from Tomcat 7.0.42 to Tomcat 7.0.64.   Do
I do  a complete de-install and re-install of the new Tomcat version and
repeat all the configurations or can you upgrade Tomcat in place from the
same series version to another one?



Thank you.





Ignacio Barragan

SDSU Research Foundation

Computing Services

(619) 594-3290

Re: Undefined behaviour with Credential Handler

[Sreyan Chakravarty]

"Feel free to do that. You'll have to implement a lot of plumbing code
yourself to use Apache Shiro. (It seems like Tomcat ought to support
Shiro, eh? Maybe we should get together with them to build an
out-of-the-box configurable component in Tomcat)."

Well I don't know that but you people could try making Tomcat Container
managed security easier to use.

On Thu, Sep 10, 2015 at 9:16 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyan,
>
> On 9/10/15 8:10 AM, Sreyan Chakravarty wrote:
> > Yes but that requires implementing your own credential handler.
>
> Sorry, I thought you had implemented your own credential handler.
>
> > But the default one will still have the bug.
>
> Oh, I was just suggesting that fix as something temporary until an
> updated version of Tomcat is released where this bug is fixed. The fix
> is trivial, so I have no doubt it will be in the next release.
>
> > Right now I am thinking of using an authentication framework like
> > Apache Shiro.
>
> Feel free to do that. You'll have to implement a lot of plumbing code
> yourself to use Apache Shiro. (It seems like Tomcat ought to support
> Shiro, eh? Maybe we should get together with them to build an
> out-of-the-box configurable component in Tomcat).
>
> - -chris
>
> > On 9/9/15 12:50 PM, Sreyan Chakravarty wrote:
>  Well I guess now its confirmed that it is a bug. Do you still
>  need the code ?
> >
> > No, I don't think I will.
> >
> > However, since you wrote your own CredentialHandler, you could
> > merely patch it to check in the matches() method for null.
> > Something like this:
> >
> > @Override public boolean matches(String inputCredentials, String
> > storedCredentials) { if(null == storedCredentials) return false;
> >
> > return matchesSaltIterationsEncoded(inputCredentials,
> > storedCredentials); }
> >
> > Then you can resume your testing.
> >
> > -chris
> >
>  On Wed, Sep 9, 2015 at 8:55 PM, Christopher Schultz <
>  ch...@christopherschultz.net> wrote:
> 
>  Sreyan,
> 
>  On 9/8/15 6:31 AM, Sreyan Chakravarty wrote:
> >>> Okay is if I have stored my password in my DB with
> >>> SHA256 encryption, can the credential handler declared
> >>> in the realm work if the it is declared with SHA512 ?
> 
>  No. SHA256 and SHA512 produce hashes of different sizes, so
>  with the same input, they will always produce different
>  outputs.
> 
>  https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions
> 
> >>>
> 
> As far as I know it must be same algorithm, salt and
> >>> iterations for the hash to be matched perfectly.
> 
>  Correct.
> 
> >>> Now take my case-:
> >>>
> >>>  >>> "org.apache.catalina.realm.SecretKeyCredentialHandler"
> >>> algorithm = "PBEWITHMD5ANDTRIPLEDES" />
> >>>
> >>> Okay this my credential handler that I am using. In my
> >>> DB the password is stored using
> >>> PBEWITHHMACSHA384ANDAES_256. A completely different
> >>> algorithm that the one specified before. So how come
> >>> when I put in my user-id and password on my form-login
> >>> page I am not getting an authentication error instead I
> >>> am being forwarded to the protected resource.
> 
>  Perhaps PBEWITHMD5ANDTRIPLEDES and
>  PBEWITHHMACSHA384ANDAES_256 are somehow aliases of each
>  other? Also, it's possible that your implementation of the
>  algorithm is flawed.
> 
>  Try running the "mutate" method from a command-line driver on
>  some sample input to see what falls out.
> 
> >>> It should use the algorithm in the CredentialHandler
> >>> to mutate the password. Now don't tell me that two
> >>> different algorithms offer the same hash.
> >>>
> >>> What is going on here ?
> 
>  My guess is a bug in the CredentialHandler itself. Can you
>  post some cod e?
> 
>  -chris
> >
> > --
> - ---
> >
> >
> >
> >
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail:
> > users-h...@tomcat.apache.org
> >
> >
> 
> >>
> >> -
> >>
> >>
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8aXyAAoJEBzwKT+lPKRYav4P/jogPWNaIJLqlX8tFLMvE4th
> 78dDP553/snHIZ+/g27ZyD2P3yIAcD1MURgO1B8k0GDJrbxQdLrtvW8jNt1J8UN8
> M0Wa68PrWxyy8uFecOhvHDwBd749teNl5Z/EimlzooC4FY5cFWCUgsY4qRAfd3/r
> aApCpSkNKOGGcJJ1RQuUYRski72H6OezzhSZthbgr+9YYtDtpxpkeJ2UikWfzeFc
> 1sl5B1wbjAl/Da8YU1tM5SNgCHLR5MAA2WDJlTyHHQrG42lhp8aE5FHVs62xT/VD
> 1v4tJP1mFNc709tKpd+hnvCczjMd4BaPP2rKmaEozhuGPyfNpPcGP1xQAmBIvWR9
> 

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/10/15 1:00 PM, Pottinger, Hardy J. wrote:
> The session attribute we are creating to hold the flag to indicate
> the session is "interrupted"... is not serializable... which I
> think means that, when the new session is created as part of 
> session fixation protection, the "interrupted" flag won't transfer
> to the new session.

Tomcat's session-fixation-prevention amounts to changing the session
identifier while keeping the session in-tact. So unless you are using
distributable sessions, this is unlikely to be the problem.

> So... I *think* what I might need to do is set a maker for our 
> request class that it implements Serializable. 
> http://stackoverflow.com/questions/763/how-do-i-make-the-session-d
ata-serializable

Only
> 
putting Serializable objects in the session is surely a good idea
in general.

> I'll let you know if this works out.

I'm interested to hear about your experience.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8dlAAAoJEBzwKT+lPKRYXtsQAJtR7dF79KCPRNjGt2jGtGwM
3r+SAmfTkNkQtxghd2VI+G8+BHUNZUzR6aNdpZcXf8N3Gwtbvpc+LRLgu7TH0d6E
A1KSSMp6V7jTW+TfLlHOa4y2T0uAzgbLwvNN6jGgRTwUNbG2eyJ/zUotQWiYWOhi
T02nNNSt2gz838Z/WSWpx/8IFS3T1i6ny4QRdFwsItFyiNJ4fV8AULVzjDp1fIdd
cuBLCFEqoMcNoWymc5IFEULtLc87Mzec52+J6robJFh1Z+2TkDSbtFWSBD2CqoPI
wIR405EUX/gaBkivnvk81J4TeOqRcEN1nc+YWPYpFbW65u0WXnG85zf58HSIaV59
Z+5FIh6/yecTJh/hRugPg/PgSIjFxo6Q2l9t2QaWqsqwNS7KyZfRqpeZWOUBJYH4
13cPBcv08LOrUUmh1tIlOpw6+3e0CqSokTtppf0Aqt8FK7ng2t7TjVrgt6GYEZGu
wMMVMboERXPFeKD618lxcn4mp89BH3iKlR3d0LDA+ZIn/68ZatDZFAUl+vhO49xn
tKKbQY6dAYx3VU8NqiXuWVup8RYRxRJlymuseUaf95GOo7JW+hvw6PbPNRYWTpMk
E6xmCdyD0hMMZXx5cnqRHBuVaXEkhbNK5o2j5WB1/sitDli/G8NUN/yN+KLrNbMC
9VRK0C/SkcNLXAosN6NP
=Wr84
-END PGP SIGNATURE-

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

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

>putting Serializable objects in the session is surely a good idea
>in general.

I agree, especially, as you mention, if we intend to distribute sessions among 
various containers.

>Tomcat's session-fixation-prevention amounts to changing the session
>identifier while keeping the session in-tact. So unless you are using
>distributable sessions, this is unlikely to be the problem.

You're absolutely right. I now have a serialized attribute, which is still lost 
upon the creation of the new session. Is there anything similar I can try, to 
ensure that the session attributes from the previous session are faithfully 
copied to the new session, after session-fixation-prevention does its thing?

--Hardy


From: Christopher Schultz [ch...@christopherschultz.net]
Sent: Thursday, September 10, 2015 2:25 PM
To: Tomcat Users List
Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/10/15 1:00 PM, Pottinger, Hardy J. wrote:
> The session attribute we are creating to hold the flag to indicate
> the session is "interrupted"... is not serializable... which I
> think means that, when the new session is created as part of
> session fixation protection, the "interrupted" flag won't transfer
> to the new session.

Tomcat's session-fixation-prevention amounts to changing the session
identifier while keeping the session in-tact. So unless you are using
distributable sessions, this is unlikely to be the problem.

> So... I *think* what I might need to do is set a maker for our
> request class that it implements Serializable.
> http://stackoverflow.com/questions/763/how-do-i-make-the-session-d
ata-serializable

Only
>
putting Serializable objects in the session is surely a good idea
in general.

> I'll let you know if this works out.

I'm interested to hear about your experience.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8dlAAAoJEBzwKT+lPKRYXtsQAJtR7dF79KCPRNjGt2jGtGwM
3r+SAmfTkNkQtxghd2VI+G8+BHUNZUzR6aNdpZcXf8N3Gwtbvpc+LRLgu7TH0d6E
A1KSSMp6V7jTW+TfLlHOa4y2T0uAzgbLwvNN6jGgRTwUNbG2eyJ/zUotQWiYWOhi
T02nNNSt2gz838Z/WSWpx/8IFS3T1i6ny4QRdFwsItFyiNJ4fV8AULVzjDp1fIdd
cuBLCFEqoMcNoWymc5IFEULtLc87Mzec52+J6robJFh1Z+2TkDSbtFWSBD2CqoPI
wIR405EUX/gaBkivnvk81J4TeOqRcEN1nc+YWPYpFbW65u0WXnG85zf58HSIaV59
Z+5FIh6/yecTJh/hRugPg/PgSIjFxo6Q2l9t2QaWqsqwNS7KyZfRqpeZWOUBJYH4
13cPBcv08LOrUUmh1tIlOpw6+3e0CqSokTtppf0Aqt8FK7ng2t7TjVrgt6GYEZGu
wMMVMboERXPFeKD618lxcn4mp89BH3iKlR3d0LDA+ZIn/68ZatDZFAUl+vhO49xn
tKKbQY6dAYx3VU8NqiXuWVup8RYRxRJlymuseUaf95GOo7JW+hvw6PbPNRYWTpMk
E6xmCdyD0hMMZXx5cnqRHBuVaXEkhbNK5o2j5WB1/sitDli/G8NUN/yN+KLrNbMC
9VRK0C/SkcNLXAosN6NP
=Wr84
-END PGP SIGNATURE-

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


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

Re: Multiple JSESSIONID cookies being presented.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/10/15 12:26 PM, Jeffrey Janner wrote:
> Thanks for all the help guys. I think I've sussed out what is
> going on here.  Now just have to get the Dev guys to address it.
> 
> After spending a good bit of time clearing and watching cookies
> and access logs, both with and without a favicon.ico file, I found
> that the doubling was happening only if the file was missing.  I
> checked the error.jsp file and it does have session=true set, and
> if the icon file is missing, the error.jsp is definitely being
> sent.
> 
> So it looks like the possible solutions are: 1) provide a
> favicon.ico file.

This fixes the symptom, not the problem. You'll get the same problem
with clients who request /apple-touch-icon.png, /robots.txt, or just
about any other file that ends up resulting in a 404. This could be
something from within the application itself, and will (apparently)
cause mass confusion.

> 2) remove the session=true setting from the error page.

This is the right answer. Do you really need the session in error.jsp?

> 3) somehow not send the error.jsp when a sub-link (image, script, 
> etc.) results in a 404.
> 
> 4) Have the login page of APP2 provide it's own icon  
> directive (it doesn't currently have one.)

> Any other options?

If you absolutely need access to the session in your error.jsp file,
you can do this:


<%
  HttpSession session = request.getSession(false);

  ...
%>

This will prevent sessions from being created when there isn't already
a session. You'll have to check the code for error.jsp to make sure
that no code uses the session before checking it for null -- because
session="true" guarantees that the "session" reference will be non-null.

That will allow you to use session information in error.jsp if a
session already exists, but not create a superfluous session when one
does not (yet) exist.

Back to Tomcat's session management: Tomcat *can* handle this
situation properly: it will try all JSESSIONID cookies it gets to find
a valid one in the current web application. So, multiple JSESSIONID
cookies won't confuse Tomcat. Some other component must be
mis-understanding the session identifier in some way.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8di9AAoJEBzwKT+lPKRY9FUP/0m2SNIG3nW9dsIRCr1q/SWG
5O/s5VrDs7Rvk1hWfbGTlhfuL0zkeCaL/GQE4wa3KQo4qHPhtzYlIgZstEeaAQqk
kLwU4JHzJcTfKMKog6/O0kFwysYzl4y/EX+UoBcY3h3N5xkQ0RGNOYEF7fSr+6NA
Uuxo6WVxQoP3Ce/64EZ1P+uxglLJF+pML6OViEHEK4qgL3SY1UY0tOFpcBa43Gqt
Y/Z7I1SvQhRt2VGQzyatHRypAMxynJfHjvV/gyF3k1/XFEeWDDpET4guaazD1uqW
fE5Lgt3Lxr1WyeEXxeJz4jOlLBty0bm9m16YFdxCsNjVy7v7Uy7M1Hd0iIfoktCV
Vp8nzuj+qxVMpzua2N/J7e9slYnIZOePOFFrTQbWx1S10QCvgRuprN3lyZEU29oP
PywXQU/F9u/xFPk6Z5+xdMrSEvL+ykuwoyV8Ef2CObZ0Ibsjx9WoBAz/hRLpeeji
TngPwFvDrU7jMR36SQ+vCR8PQSjQo5P2P+KZE735uIgG/iz3F6gQ+8R9E0p1iutL
iLoF2alPkSaoWnBTrlDhV+EvKtjKl2FWuRrs5sHGWG6FowS+lKnaAfhkq3ArGLdS
j4JFculpE80Ys9saoetvTlQ35dTi1KdmL+gzixI/EjUVkS2azsW6kYxkwliig4gN
UVa6wuFsD/I9JcMCKeIp
=1OQG
-END PGP SIGNATURE-

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

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote:
>> putting Serializable objects in the session is surely a good
>> idea in general.
> 
> I agree, especially, as you mention, if we intend to distribute 
> sessions among various containers.
> 
>> Tomcat's session-fixation-prevention amounts to changing the
>> session identifier while keeping the session in-tact. So unless
>> you are using distributable sessions, this is unlikely to be the
>> problem.
> 
> You're absolutely right. I now have a serialized attribute, which
> is still lost upon the creation of the new session. Is there
> anything similar I can try, to ensure that the session attributes
> from the previous session are faithfully copied to the new session,
> after session-fixation-prevention does its thing?

It's simpler than you think. Tomcat really does nothing other than
this after successful authentication:

 session.setSessionId(randomNewSessionId);

The "new" session is in fact the same as the old session -- it just
has a new identifier. The client will get a Set-Cookie response
changing the JSESSIONID cookie value, and any URLs encoded with
HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL
will include the updated session identifier (if appropriate).

So the "loss" of your session attribute is puzzling. You could write a
noisy HttpSessionAttributeListener that logs every session-attribute
event (with a stack trace) to see if that attribute is being removed
elsewhere.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8eCiAAoJEBzwKT+lPKRYYoAP/3oMiZPb3Dwe8Ty74DEtvg5D
FD4aWQv4hkyhKDCpFAfpVkZYy/Y6sokF2SJteX5INALZ0Uq+w7NKR8z1LdtSAklF
867e/UKYryJnCSlYj2qbitmc9uZ5ivjfWa1lnl/umYsS4lo5RfYOhEJsCahWtOuo
O2DyGcIICqdLQ7W/3kw4Yk+ykypAmGSbmrbUHACVvEAm4318q/W+2oEPwEkmxw3f
qyW/RGtHaLndpruU+p+4uxGh+b/N3RE/R8ZTWvjLtTfIe/XgZyqb+2C3MmV/BbBC
D9IEAqRPchXbnOKBry6j9CYrtWtl9fj2HjbLaXg/ZgNQkDf39gtFB/bdIZVvbcex
CqsCZ9Gm56Cv84O0fWZghXj+kVA0U7vimzeaig8//d3O7OuyzcKOyqvn7/QyQmh5
VVLVVeoVitrio4nlcbrIvAxDf3XUUztDq0YXow0v569emuHnbFikoYNjHcfKaj52
jCEwHrPVPHId0mh22+7lFAIjMjxb6a/vJUwfD0pU+JKlqklMtZmaW2lpyH72J4n5
8VbbLQvrZbi85UfkHhoYmU5/0RdWIlMSuMNXW7EMPZ+EYVaJWMhndyVN0dON3/fV
PojLz02Ye1EQn4kdyiaD288NGtoCyXfc9+tcMgm3e3sBZuMbCy9NwdjVrx9ChVcO
QS8LMEVu0FMhri8oNk/p
=lKTi
-END PGP SIGNATURE-

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

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

I can see in our log files that we log the session ID as part of the 
authentication process so it's probable that our authentication code needs 
a bit more work to accommodate the changing session ID. I'll see if I can 
figure it out.

From: Christopher Schultz [ch...@christopherschultz.net]
Sent: Thursday, September 10, 2015 2:57 PM
To: Tomcat Users List
Subject: Re: seeking help with stabilizing the persistence of a JSESSIONID

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote:
>> putting Serializable objects in the session is surely a good
>> idea in general.
>
> I agree, especially, as you mention, if we intend to distribute
> sessions among various containers.
>
>> Tomcat's session-fixation-prevention amounts to changing the
>> session identifier while keeping the session in-tact. So unless
>> you are using distributable sessions, this is unlikely to be the
>> problem.
>
> You're absolutely right. I now have a serialized attribute, which
> is still lost upon the creation of the new session. Is there
> anything similar I can try, to ensure that the session attributes
> from the previous session are faithfully copied to the new session,
> after session-fixation-prevention does its thing?

It's simpler than you think. Tomcat really does nothing other than
this after successful authentication:

 session.setSessionId(randomNewSessionId);

The "new" session is in fact the same as the old session -- it just
has a new identifier. The client will get a Set-Cookie response
changing the JSESSIONID cookie value, and any URLs encoded with
HttpServletResponse.encodeURL or HttpServletResponse.encodeRedirectURL
will include the updated session identifier (if appropriate).

So the "loss" of your session attribute is puzzling. You could write a
noisy HttpSessionAttributeListener that logs every session-attribute
event (with a stack trace) to see if that attribute is being removed
elsewhere.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8eCiAAoJEBzwKT+lPKRYYoAP/3oMiZPb3Dwe8Ty74DEtvg5D
FD4aWQv4hkyhKDCpFAfpVkZYy/Y6sokF2SJteX5INALZ0Uq+w7NKR8z1LdtSAklF
867e/UKYryJnCSlYj2qbitmc9uZ5ivjfWa1lnl/umYsS4lo5RfYOhEJsCahWtOuo
O2DyGcIICqdLQ7W/3kw4Yk+ykypAmGSbmrbUHACVvEAm4318q/W+2oEPwEkmxw3f
qyW/RGtHaLndpruU+p+4uxGh+b/N3RE/R8ZTWvjLtTfIe/XgZyqb+2C3MmV/BbBC
D9IEAqRPchXbnOKBry6j9CYrtWtl9fj2HjbLaXg/ZgNQkDf39gtFB/bdIZVvbcex
CqsCZ9Gm56Cv84O0fWZghXj+kVA0U7vimzeaig8//d3O7OuyzcKOyqvn7/QyQmh5
VVLVVeoVitrio4nlcbrIvAxDf3XUUztDq0YXow0v569emuHnbFikoYNjHcfKaj52
jCEwHrPVPHId0mh22+7lFAIjMjxb6a/vJUwfD0pU+JKlqklMtZmaW2lpyH72J4n5
8VbbLQvrZbi85UfkHhoYmU5/0RdWIlMSuMNXW7EMPZ+EYVaJWMhndyVN0dON3/fV
PojLz02Ye1EQn4kdyiaD288NGtoCyXfc9+tcMgm3e3sBZuMbCy9NwdjVrx9ChVcO
QS8LMEVu0FMhri8oNk/p
=lKTi
-END PGP SIGNATURE-

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


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

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/10/15 5:08 PM, Pottinger, Hardy J. wrote:
> I can see in our log files that we log the session ID as part of
> the authentication process so it's probable that our
> authentication code needs a bit more work to accommodate the
> changing session ID. I'll see if I can figure it out.

If you store the session id somewhere instead of always going-back to
the actual session object to grab its id, you may have a problem.

I believe there is a (non-spec-standard) listener you can attach that
will be notified when sessions change ids.

- -chris

>  From: Christopher Schultz
> [ch...@christopherschultz.net] Sent: Thursday, September 10, 2015
> 2:57 PM To: Tomcat Users List Subject: Re: seeking help with
> stabilizing the persistence of a JSESSIONID
> 
> Hardy,
> 
> On 9/10/15 3:36 PM, Pottinger, Hardy J. wrote:
>>> putting Serializable objects in the session is surely a good 
>>> idea in general.
> 
>> I agree, especially, as you mention, if we intend to distribute 
>> sessions among various containers.
> 
>>> Tomcat's session-fixation-prevention amounts to changing the 
>>> session identifier while keeping the session in-tact. So
>>> unless you are using distributable sessions, this is unlikely
>>> to be the problem.
> 
>> You're absolutely right. I now have a serialized attribute,
>> which is still lost upon the creation of the new session. Is
>> there anything similar I can try, to ensure that the session
>> attributes from the previous session are faithfully copied to the
>> new session, after session-fixation-prevention does its thing?
> 
> It's simpler than you think. Tomcat really does nothing other than 
> this after successful authentication:
> 
> session.setSessionId(randomNewSessionId);
> 
> The "new" session is in fact the same as the old session -- it
> just has a new identifier. The client will get a Set-Cookie
> response changing the JSESSIONID cookie value, and any URLs encoded
> with HttpServletResponse.encodeURL or
> HttpServletResponse.encodeRedirectURL will include the updated
> session identifier (if appropriate).
> 
> So the "loss" of your session attribute is puzzling. You could
> write a noisy HttpSessionAttributeListener that logs every
> session-attribute event (with a stack trace) to see if that
> attribute is being removed elsewhere.
> 
> -chris
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8fLsAAoJEBzwKT+lPKRYWDAP/jjiOE3HurXXYMKfy02+kONx
ao4Bz7ne/zQX7lXBgBuI+lF4MS78oXWx2rp5nF3H/VPXAZ2JesgfwU+U+VbagU8m
7PjCBQaY4QyceyJg7PkSdAT130xif/9sdlmml+qDBSRogBb8cO7TLxxPQZeL808I
+1FL5KnAb5JK3jIwYkYY0/IH/r2zaMYeawHofyP+uDLvGQmz3fCJfTq5T0IZYAcy
P2tiId0dVxmlF70mcP71SVeHNowBKkNucNCnubM1rNPxCc84zgbvc6mYw6jf2Daq
5MlRyCLrjFaTlEHkLkIjlbLHav5CXFkom7jvBlg1jv852Wzjf3RKmzCzzPOSAsvd
GCxi54wU9j0LDFwxBvyro14j56eBlaPcT//7VrZDrL8/HHv37PvivYZ0Iw8dTTls
kNKPzFHg0FVYj3kq8DDof3H1YJ+LV8LalRYS/qqv/LAxzq9lSe5qObovd8MoVuPz
/IePfZLkNV9cLVZo/iIuvfrpKY41gdGD1hrlY9+F6BPhPHoNpCj5n1r7UK9F38gr
qXP5IdrpN7uSnMGpzvbXYSwrRswBTyQVShqsdCVJQWS++GLjLDWxdv/fxbYXc9ac
oMyeEoCpinzJ+MmTMIc9dAJecGUDayJP+KMQvabPUkd4Ee33R+27P9/zoQI12Sds
4uCO7ksTV7qLWpjybm3o
=n+Ja
-END PGP SIGNATURE-

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