Re: Tomcat Session issue - Session not expiring on browser close event

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kiran,

On 9/7/15 12:54 PM, Kiran Badi wrote:
> I have few attributes saved in session they seems to living for
> close to 30 minutes which is session timeout in web xml.
> 
> I need to kill the session once the browser closes on the client
> side.

You need to free server resources, or you want the client to be
disconnected from their (old) session?

> Is their a way to do it on server side rather than doing via some
> kind of ajax handler.

Yes and no.

If you have the cookie set with no expiration date (the default with
Tomcat's container-managed sessions), then the browser will forget the
cookie when it closes.

If you *do* have an expiration date on your cookies, then AJAX is the
only way, and there's no guarantee that the browser is actually going
to send that AJAX message when it's closing the page.

If you want the serer to kill the session immediately upon browser
close (regardless of "expiration" date), your only hope is AJAX, and I
can tell you right now you shouldn't bet on that working.

> Doing it via ajax means injecting that code in all my jsp's and
> have lot many.

Sounds like session cookies are the way to go.

Perhaps you should think about using a leaner session, and then
sessions living for longer than necessary won't be such a big problem.

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

iQIcBAEBCAAGBQJV8DVQAAoJEBzwKT+lPKRYG4gP/0qOpYTP5D0xmPVZAaHFAhFY
Guz8sdBXxnfWlYwWYDZMcbtpOjpi91i5N9W42X0oeFTttkXH5Dzvfo7TpYo9OPnv
RRNdQZncehtlH0nZKjU7rnDFkiCUBWr6/LiblJikOMleItCZDfDIUpmakX7mgs+w
P0Y976SgdIPVxFjlqXc+Pgxnup6t8lFcNmrBPe93Jmb9QxzL1o4qcevdTz7KVdwo
BRKPHOEAGXTawcJM9E14e2tUa/8J+M7kTovoCkxjK5+VQSi+2k5KDmMDlxEdn6iO
HPSwpvsHxNyWd21rREIQhNfWOADYar5+phw5g+ifGtRxfhbY+cGzD2DzfrsUkZQB
+a0iGf9OgQb/wFIONWZbbx1zl6IQTiajZjuKuSfA5CXYDLbnyfsIMQ1Y77tlSZIZ
ZIw6k2NiRzKgMm54Fnms8ixAGtIHX9j7qGaJvGVQjc0ZxIexsrp9DgzWt6+BmRbD
H7gMmcT/pl4UzI6fSlOm9d8E/PtL3sd7pGQhEwVb4Y9U1Ihq/bHlPHrTsn0I14H3
UYZpDFKGHHH8I7r7OrBiMFSWICNsNL2c4BgRU/uzTvEivCRrnJBUjzVGtWsYscvj
HwwTxUzIMnUOe+Uc09PDmh231vKhFYIWsdFDR1MFPQfZUZ9MYPe49xxmLq0rmo4+
tqTv8vYdaMtWWbmd+G6B
=tPe/
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/9/15 9:45 AM, Christopher Schultz wrote:
> On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
>> I have found the cause of the problem. It seems that there is no 
>> null checking in the DataSourceRealm in Tomcat. What I mean is
>> that if a particular user does not exist in the database and is 
>> credentials are returned as a null string then no null checking
>> is specified.
> 
>> I would like to open this as a bug.
> 
> https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
> 
> Before you file a bug:
> 
> 1. Make sure you test on Tomcat 8.0.26 2. Make sure you post a
> stack trace from the NPE 3. If you can provide a simple test-case,
> it would be helpful
> 
>> The easiest solution is to write a custom Realm that provides
>> the null checking. The only problem is that now why am I not
>> being redirected to the error page if I provide a valid user with
>> a wrong password.
> 
> If the authenticate() method returns false, then Tomcat should
> send the user to the form-error-page. It may not issue a redirect,
> but instead perform a forward. Is that a problem?
> 
>> Please if anyone can tell me how to write a custom Realm then it 
>> would be really appreciated.
> 
> If this really is a bug, it should be fixed. I'm skeptical at this 
> point, since nobody has reported this yet. It would be a fairly big
> bug.

Confirmed by code inspection that Tomcat does not check the return
value from DataSourceRealm.getPassword. Exactly where the bug lies is
a matter of opinion:

1. DataSourceRealm blindly passes the stored credential to the
CredentialHandler
2. MessageDigestCredentialHandler.matches() performs null-checking of
its arguments
3. SecretKeyCredentialHandler.matches() does not perform such
null-checking

I think it's appropriate for the entire system to waste a little time
performing the credential-checking algorithm when the username is
invalid because it mitigates timing-analysis used to perform user
enumeration. That could be done in each of the individual
CredentialHandler classes, or it could be done in the Realm itself. I
would argue it makes sense to do in the Realm, but the handler itself
could implement such a mechanism, too.

Opinions are welcome.

Please log the bug.

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

iQIcBAEBCAAGBQJV8Do2AAoJEBzwKT+lPKRYNQEP/R1W9tPPrkmRCJMpy+JT63Y1
GcUblu/0ho1xGd0/NQerpOrePJlAL94RPTkEBCw26DjHZOZ6ehYjgXHBApCIFmze
LIMlI/x1xe63YgYx19VTCmGv48kLJa97XuoDgHa0Uo2RrAvtG7SaoIiBbFGoI+ID
J+Ki0ntNvRZshrp4I9GvN9o+HpX19MVmW0Sj58P5a2DpdxwavF3gFRzgpkq8Rxdy
W+Unbpx4/klI5Gp1W/bp+5j5u8xAS0+KxtsWxzD9ujjHhCCteDqr+2xZVmv4pR3P
NUlHIdNa6ufOAP6TPM0eQTlFiyx2zRAAJlogCJ1jdYgWe2buaFvmPmFUG8q8JCLQ
ggdVhtYo4qT1NNr+C0JWvYpmE25IlQN462cIXbcLV43wTReVaNDeeaVWQgwZLiMa
3TVS9C5UNGhSVKwPJriHsOECogaswA2fgJSUmDo25zaUAPTul7tT4TsxWbvKuTMI
QUhAwsm5kqWhv8j9SbphMkmTG2lBBJDczZlemdjHGxofO3dH6q0TtLeR/1ipy9MN
FML+r3P3D/l08pIPFbU1d2WT32Fvk77f2+x7Zijjx7XJH0gzZT3cGL4z3VtQPfFn
6ulWUT6EMsW4g59NEsWyWUPwoQxdyzbXq3QTgygHslEC4vNlOmoewz3uCJLWm0Gd
MjZcERouuPKa+PiNJBuE
=l21+
-END PGP SIGNATURE-

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

Fwd: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

I have found the cause of the problem. It seems that there is no null
checking in the DataSourceRealm in Tomcat. What I mean is that if a
particular user does not exist in the database and is credentials are
returned as a null string then no null checking is specified.

I would like to open this as a bug.

The easiest solution is to write a custom Realm that provides the null
checking. The only problem is that now why am I not being redirected to the
error page if I provide a valid user with a wrong password.

Please if anyone can tell me how to write a custom Realm then it would be
really appreciated.

Regards,
Sreyan Chakravarty

On Mon, Sep 7, 2015 at 10:51 PM, Sreyan Chakravarty <
sreyan.mail...@gmail.com> wrote:

> Yes but what happens when the user passes a user-id that is not present in
> the DB. Or a password that is incorrect. How would the server handle that ?
>
> If I pass an incorrect user I am getting a NPE. And if I pass an invalid
> password but a valid user a am not being redirected to the form-login-error
> page.
>
> That was my question. How do I do that ?
>
> On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) 
> wrote:
>
>> Hi.
>>
>> I have notv really followed this thread from the beginning, but maybe I
>> can contribute something here..
>>
>> On 07.09.2015 15:56, Sreyan Chakravarty wrote:
>> ..
>>
>>>
>>> Also can I webapp have different realms ? If so how do you distinguish
>>> them
>>> ? I was looking at the RealmBase source and I haven't noticed a place for
>>> realmName. If not then what is the use of the  element in
>>> web.xml ?
>>>
>>>
>> One webapp can only have one realm, but several webapps (or let's say
>> more generically several areas in "URL space" on the server) can share the
>> same realm.
>>
>> The "realm" is something that the server sends back to the browser in the
>> "401 Authorization required response".  It is just a "label", which in
>> terms of AAA, identifies a certain collection of resources on the server,
>> covered by the same authentication/authorization requirements.
>> In the server configuration, you can choose yourself which resources are
>> covered by the same realm (label).
>>
>> It is easier to explain this by example, in the general context of the
>> HTTP protocol.
>> The basic way in which AAA works in a webserver is this :
>>
>> 1) the client/browser sends a request to the server, with a specific URL,
>> which resolves on the server to some resource
>> 2) the server evaluates the request, and resolves the resource to which
>> it applies (e.g. a static html page, a servlet, ..).  The server then
>> checks in its configuration, if this resource is protected.  If not, it
>> returns the requested resouerces to the client, and that's it.
>> 3) if the request is protected, the server checks if the request contains
>> some form of authentication. If yes, the server checks if this
>> authentication is valid, and applicable to this resource. If yes, the
>> server returns the requested resource, and that's it.
>> If not, the server returns a "forbidden" response.
>> 4) If the request did not contain an authentication, the server returns a
>> response to the client : "401 Authorization required", along with a realm
>> (the "label" applicable to this resource, as per the server configuration),
>> *and* the required authentication method (e.g. "Basic" or "Digest").
>> 5) the client sees this response, and interacts with the user to obtain
>> the required user-id/password.  Once obtained, the client/browser repeats
>> the same request to the server, but this time with some additional HTTP
>> header(s) containing the requested authentication.  At the same time, the
>> client/browser "remembers" this authentication, and remembers to which
>> "realm" it applies.
>>
>> Then go back to (1) above.
>>
>> If the client/browser (within the same browser session), later accesses
>> the same or another resource, and it receives from the server another 401
>> "auth required" response with a realm in it, and the browser knows that
>> *for this same realm* it already had a remembered authentication, then it
>> can send the same one again to the server, without needing to ask the user
>> again to fill-in a login dialog.
>>
>> This is a pure HTTP-level mechanism, which works independently of any
>> "session" that one may have on the server (as long as the authentication
>> method is "Basic" or "Digest").
>>
>>
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/7/15 9:56 AM, Sreyan Chakravarty wrote:
> I did what you said. That is pointing the web browser to a
> protected resource without authentication and then logging in. It
> works perfectly IF AND ONLY IF the credentials are ABSOLUTELY
> correct. Otherwise I am getting undefined behavior an thats where I
> need your help now.
> 
> First-: If I provide an invalid user-id and valid/invalid password
> I am getting the following error-:
> 
> HTTP Status 500 -
> 
> java.lang.NullPointerException 
> org.apache.catalina.realm.DigestCredentialHandlerBase.matchesSaltItera
tionsEncoded(DigestCredentialHandlerBase.java:147)

What
> 
version of Tomcat are you running? That line number is a javadoc
comment in both Tomcat 8/trunk and Tomcat 9/trunk.

> Now I thought that when invalid credentials of any kind are given
> Tomcat is supposed to take you to the . Then why
> is it I am getting a 500 error. Clearly something is wrong from my
> side or else the  is invoked under different
> circumstances.

It's possible there is a bug in there; the CredentialHandlers are
fairly new. But I'm gong to need a test case to check it out. Can you
create a quick WAR file containing whatever is necessary to reproduce
this on an up-to-date Tomcat 7/8/trunk? I'll need a copy of your
custom credential handler as well, and any configuration from
server.xml that is necessary.

> Secondly-: If I provide a valid user-id and invalid password I am
> again not redirected to the form-error-page I am kept in
> j_security_check.

What do you mean by that? Were you expecting a formal redirect response?

> How do I show the user that is credentials are wrong?

The form-error-page should be used when credentials are invalid.

> Also can I webapp have different realms?

Yes and no. The web application can only have a single Realm, but
there is a Realm called CombinedRealm that allows you to register as
many realms with it as you want.

> If so how do you distinguish them?

- From client code, I'm not sure it's possible.

> I was looking at the RealmBase source and I haven't noticed a
> place for realmName. If not then what is the use of the 
> element in web.xml?

That's for HTTP Basic and HTTP Digest authentication: it's the "realm"
name that is displayed to the user when the username/password pop-up
is shown to them.

> The example that you have provided -:
> 
> request.login(req.getParameter("username"), 
> req.getParameter("password"));
> 
> Which realm would it use if there were multiple realms available ?

The only realm for the web application (which may be a CombinedRealm,
in which case you won't be able to tell which realm successfully
performed the authentication).

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

iQIcBAEBCAAGBQJV8DcwAAoJEBzwKT+lPKRYWIgP/jd1st1bvPD5xojhLl/D+fdz
zVQGejG9dCIW7RHNIt8BrHi/CL+Nf2Q1bEFrnIPbCHsBMQwsCvKdCf8dR9iWf6jH
LHiX9hHakf04aFc0LEkYHUkFIU9rFNKNTggSv1OKMb4JIcBZYyTS9bB8PZsWeWJM
qCJmn0Ga9zntDUzBwpnJXT8LKxAGqV1N980crmIjXLLVcbPhNSaK/+PmMn2cnYVc
nLuFOcO2ssrCp6/AcQrrP7w0sD9duzPIesLsebbxbiyw9ME15o0OTFbJ902itzPF
oBmH48sgh6z3vYzGoQHT7uh+jl8iCKLn3AqSucC2dkCcEiIWjRC4g2vtdbPtUyiy
3diqXYiDUonIRk4Xat3wScxmriOSbcX/LCgNIHTagpcXbfGnt40QgfjKuO+dm4bV
65SK/iJjswcmvJa1J0aRXs8gmPQ9Y1UbTdDIOZ5gMfCxY6rF4HkzroW8r7+zuuqF
ZUq870vCsAJk3+VOfzS0Uv3SoKBZgTc+6tReIp/CWT7gLoCysoqeXeWvDLB82v71
bHe5s+UQNYxDSJhrLZ+Y4ic1YzwffJEbI0+1+DvSuq3SaE+WFjZiinPjIhv1R6i7
WNVp25v5cyfdC6ihRztmlrVKwEniUUjm9ocKAcZgASXPOdAXrkwJ7ybBa5Ez8DbS
gi/jxgOSZZw7ddZC0rzK
=5Uty
-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: Igor Cicimov [mailto:icici...@gmail.com]
> Sent: Tuesday, September 08, 2015 10:09 PM
> To: Tomcat Users List 
> Subject: RE: Multiple JSESSIONID cookies being presented.
> 
> On 09/09/2015 7:13 AM, "Jeffrey Janner" 
> wrote:
> >
> > > -Original Message-
> > > From: Jose María Zaragoza [mailto:demablo...@gmail.com]
> > > Sent: Tuesday, September 08, 2015 9:22 AM
> > > To: Tomcat Users List 
> > > Subject: Re: Multiple JSESSIONID cookies being presented.
> > >
> > > 2015-09-08 15:51 GMT+02:00 Jeffrey Janner
> :
> > > >> -Original Message-
> > > >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> > > >> Sent: Friday, September 04, 2015 12:46 PM
> > > >> To: Tomcat Users List 
> > > >> Subject: Re: Multiple JSESSIONID cookies being presented.
> > > >>
> > > >> -BEGIN PGP SIGNED MESSAGE-
> > > >> Hash: SHA256
> > > >>
> > > >> Jeffrey,
> > > >>
> > > > Now, it's been doing this since at least Tomcat 6, I have one
> running
> > > now, and I've never had a problem with it using direct connections.
> But
> > > now we are front-ending with HaProxy and going to two backend
> tomcats,
> > > and using the JSESSIONID to support sticky-sessions.  I'm afraid the
> > > multiple cookies is confusing HaProxy. (Yes, I'm going to ask that
> user
> > > community.)
> > > > Jeff
> > >
> > >
> > > You could use another cookie to implement stickyness
> > >
> > > "You can add a cookie SOME-COOKIE-NAME prefix directive into the
> > > backend. Then simply add the cookie directive within each server.
> Then
> > > HAProxy will append a cookie (or add onto an existing one) a
> > > identifier for each server. This cookie will be sent back in
> > > subsequent requests from the client, letting HAProxy know which
> server
> > > to send the request to. This looks like the following:"
> > >
> > > backend nodes
> > > # Other options above omitted for brevity
> > >  cookie SRV_ID prefix
> > > server web01 127.0.0.1:9000 cookie check
> > > server web02 127.0.0.1:9001 cookie check
> > > server web03 127.0.0.1:9002 cookie check
> > >
> > >
> > > https://serversforhackers.com/load-balancing-with-haproxy
> > >
> > Thanks Jose.  We considered that, as well as having HaProxy just
> generate
> its own sticky-session cookie, but it seemed like a better idea to just
> let
> Tomcat handle it and use stick-tables. We are moving towards a
> fully-clustered tomcat, so already having the config in place such that
> we
> only have to turn off the stick-tables and we'd be set to go. I'll
> eventually be supporting a fairly large number of backends and don't
> want
> to make the configuration of new ones very complicated. Making them
> simple
> and pushing the complication down to the tomcat level just seemed to
> make
> more sense.
> 
> If using more than one haproxy inserting its own cookie is much better
> solution since you don't have to sync the stick tables between the lb's.
> 
> > In fact, I've parameterized the jvmRoute setting in the Tomcat
> server.xml
> and use the setenv.sh script to calculate the value based on the server
> the
> Tomcat is running on.
> > If only there were some way to have HaProxy read an already existing
> suffix in the cookie string, like httpd, my life would be perfect.
> > Jeff
Thanks Igor.  We may have to look into that in the future. We are running 
multiple HaProxy servers relying on Round robin DNS, so we need to have some 
method of insuring a consistent cookie between the two HaProxy servers. 
Thanks again.

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
> I have found the cause of the problem. It seems that there is no
> null checking in the DataSourceRealm in Tomcat. What I mean is that
> if a particular user does not exist in the database and is
> credentials are returned as a null string then no null checking is
> specified.
> 
> I would like to open this as a bug.

https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208

Before you file a bug:

1. Make sure you test on Tomcat 8.0.26
2. Make sure you post a stack trace from the NPE
3. If you can provide a simple test-case, it would be helpful

> The easiest solution is to write a custom Realm that provides the
> null checking. The only problem is that now why am I not being
> redirected to the error page if I provide a valid user with a wrong
> password.

If the authenticate() method returns false, then Tomcat should send
the user to the form-error-page. It may not issue a redirect, but
instead perform a forward. Is that a problem?

> Please if anyone can tell me how to write a custom Realm then it
> would be really appreciated.

If this really is a bug, it should be fixed. I'm skeptical at this
point, since nobody has reported this yet. It would be a fairly big bug.

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

iQIcBAEBCAAGBQJV8DgVAAoJEBzwKT+lPKRYTfwP/A1tstT6mwueYnnjIT34HSji
Tu8OasywHIVPmVQ07jC7pkvysCGtOegGyWuymAilDWNEqiBsNuUmnMMuL/jJNm1D
8GLb0V8tazbxlNWsHyQ7Gg8XPEDvuRWjzJVNpCrHDbdrwOhKz0DnejxjPyXpSGkq
b2xyS+ay7iD8VLfohmclM6LD1Kp7+MdIwtnTPag5GvkAErwRQ9XmoByTVV1cZPbC
JToYerhP1kMepfF1M9K+XSotkod1xWYvq21sz2AC7sV/0kdcwOyZ/NWYqZSSdvbt
VlwQxcLqkliV6GRD/TRWduXrk36KwbNsgLNISTqjMwgBmL5HjLV7LmegL/kfK97u
J0ijssLVs/NA5BahEzmmDN/q3PfYrc7HWYJTeutt4T9obwuLqIFOoHZHPVKHj5vr
BZxWrgBVWULWw2MRpFooE4QiMaFHsLun7U/vLsKHT4ledJwPOt65UM0ARF06nZwV
htQfMkVFzqaM51+ZyJn4WBtGSwkQM1Mk8BARl5dOcH319GERRQB3ttLqJbSfmSca
PO38R6t3u0uvRmFHQqD11WHECEDWrt7rZbohyQSAX8acQb31pytrDPy4YsDDOk/o
fLpJ3v92ZGlnr22E1epziE5/bVzUywVmPkBTymJDKotOvYApu1FjUBINfyftsK71
rc3wYFqoC35+Oy29vvek
=ocBg
-END PGP SIGNATURE-

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

Fwd: Undefined behaviour with Credential Handler

[Sreyan Chakravarty]

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 ?

As far as I know it must be same algorithm, salt and iterations for the
hash to be matched perfectly.

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 error
instead I am being forwarded to the protected resource.

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 ?

Regards
Sreyan Chakravarty

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

Hi, thanks for following up! No, no luck at all. The web application I'm 
working with is based on Apache Cocoon 2.2, so, no JSPs in sight. I am actually 
weighing my options, I have a choice to either pursue making the current design 
work (i.e. try to get the session to stick around long enough so I can use it), 
or else change the design and go with a more conventional "pass the return URL 
around as a parameter in the request" approach. I'm leaning towards the latter, 
as it sidesteps this whole issue we're having with session fixation protection, 
*and* it deals with a slightly esoteric use case, where a user encounters a 
password challenge when attempting to view a restricted item, backtracks, then 
later chooses to log in for some other reason, and is returned to the original 
restricted item page (because the redirect URL is still in the session). 

If I do continue to persue the session route, I'll let you know if I'm able to 
determine what authentication class ends up in the stack trace.

--Hardy

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
>> Are you using AJP or HTTP as your proxy protocol? If AJP, are
>> you using tomcatAuthentication="false" on your ? I'm
>> not exactly sure what happens when you do that... you might get
>> a NonLoginAuthenticator.
>
> in our Vhost file, we have this:
>
>  ProxyPass ajp://127.0.0.1:8009/xmlui
> retry=1 keepalive=on ProxyPassReverse  ajp://127.0.0.1:8009/xmlui
> ShibUseHeaders On SetEnv proxy-sendchunked 1 
>
> in our server.xml file, we have this:   port="8009" enableLookups="false" redirectPort="8080"
> protocol="AJP/1.3" address="127.0.0.1"
> tomcatAuthentication="false" maxSwallowSize="-1"
> connectionTimeout="1232000" disableUploadTimeout="false"
> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
>
> So, we're using tomcatAuthentication="false"
>
> I will try your suggestion of using NonLoginAuthenticator and see
> what I get. If it doesn't work, I'll try your suggestion of setting
> a breakpoint and using a debugger to look at the stack.

Any luck?

You don't have to use a debugger to get a stack trace: just create a
JSP and have it 'throw Exception("getting a stack trace")'.

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

iQIcBAEBCAAGBQJV8DLwAAoJEBzwKT+lPKRY48YQAIUdyi1UwJTtdmjJBRWLXH7Q
ochdn2fBkBF+nDn1V3mLp7svDrk4SNFdymRUudOgCg4ZF4GHVClYDEVcQFMYKgOB
7NjBNtxTLXKhX7AloY+nYHJaCBEcKsYW3fZXCmNt1/KKCXq2cEcJ264++VUN//sT
khvWjTipOuDQAZYauWfQWb2T4flp5Viitq37zyYpeTD1HeTxepdTFAlPIquFYAlK
bHQQuWpI55YjTTBoDq3+FKabH97DQ1A3mLYcktIvIT4KiHFFlE2F+mb30F60Qdw7
RRDFJhTFGbnr0gIIV1b6VUJyDhh6m4bIXkRCixo41d9JAzzcmkpivaEClO+YTFwF
X8nVRPFkRiFKgKU6Gw0g/fzMNz53LrhW5TPvy7nHe2f+Ahip0M94pS3sD0azh+y0
ZoxG9JyquDQWHPGgwfQqjtide7+u5bo8mEhuUC2tWNl7iSwB7rUFgz9GgyWl7fNi
jRRZ3gCrqaZFdUoJdh9/eUpfzo24DNEPO5mNsD5Ii0REXXGHkalVd1Rk6MyYFc+X
Jt4ZJVG2Jxlcu3Z2G9wUfNBuc/0ejsmHuOKlLeg0++J0QIoKOwZw67k5HD/XoUhT
ieSV9f2LZwA5Wh3vA4o80uC94SWU/4aav6D0qhB5Np6YXy7xtX/q/oGSVu6sr0XY
zg8u3mC90npBIj5b3nPQ
=kWRl
-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

FW: Issue in reading SSL certificate

[Hirnya Kaushal]

Dear,

 

I am facing a very peculiar issue with the SSL certificate for Tomcat7. I am
using Java 7 and Tomcat 1.7.075. and facing the below issue with the SSL
certificate. I have followed the below steps to generate the certificate and
apply same on server.xml.

 

Generated the CSR file by using the keytool on the server.

1)  $JAVA_HOME/bin/keytool  -genkey -alias server -keyalg RSA -keysize
2048 -keystore /opt/hirnya/mobileweyakae.jks

2)  $JAVA_HOME/bin/keytool -certreq -alias server -file
/opt/hirnya/csr.txt -keystore /opt/hirnya/mobileweyakae.jks

Shared my case file with CA provider and received back chain.p7b file. And
followed the below step to import the key tool (I tried 2 ways to apply the
same but the end results and the error on the tomcat logs are almost same.)

1.  Double click .p7b file on windows
2.  Expand the node certificates from the left side.
3.  On the right side the list of certificate occurred.
4.  Double click the required certificate to open it.
5.  Click the details tab.
6.  Click the "copy to file..." button
7.  click next
8.  select the 2nd format (Base-64 encoded X.509 (.CER))
9.  Enter the file name (As original file name). Please make sure the
file location (Directory)
10. Read the export wizard setting and then Press "Finish" button.
11. Repeat the same steps for all 3 certificates.

Then, transferred the all certificate on same path where I have generated
the csr file and imported the file with 2 different way. 

 

Steps of Process one applied:

Imported the files received from CA with below command and applied with all
files received from CA.

$JAVA_HOME/bin/keytool -import -trustcacerts -alias root -file
/opt/hirnya/root.cer -keystore /opt/hirnya/mobileweyakae.jks

$JAVA_HOME/bin/keytool -import -trustcacerts -alias abc -file
/opt/hirnya/server.cer -keystore /opt/hirnya/mobileweyakae.jks

$JAVA_HOME/bin/keytool -import -trustcacerts -alias mobile -file
/opt/hirnya/mobile.cer -keystore /opt/hirnya/mobileweyakae.jks

 

Attached is the view of certificate generated (crtifacate-process1.txt) and
the tomcat logs ()tomcatand below is the configuration for SSL on tomcat.

 



 

 

Steps of Process Two applied:

 

Exported the keystore to the pem file.

 

1)  $JAVA_HOME/bin/keytool -exportcert -rfc -file /opt/hirnya/server.pem
-keystore /opt/hirnya/mobileweyakae.jks -alias server

2)  Open the pem file with cat and added the other certificates received
from CA into the same file and generated the bundle.pem file, attached is
the file for reference. (this includes all the certificates)

3)  Then imported the certificates to the keytool with below command

$JAVA_HOME/bin/keytool -importcert -keystore /opt/hirnya/mobileweyakae.jks
-alias server -file /opt/hirnya/bundle.pem.
 
 
The certificate generated output is attached as certificate-process2.txt for
reference and the logs of the tomcat as well.

 

 

In both the case I am able to reach the https:// but receiving the security
error and only reading the self-generated key and not able to read the
imported key.

 

Attaching the generated key files(mobileweyakae.jks) and certificate
(hirnya.zip) as well for your reference.

 

Thanks in advance for your support.

 

 

Thanks & Regards,

Hirnya Garbh Kaushal,

MobiSoft Telesolutions(Altruist Group)

Mobile(Dubai,UAE): +971 564745875

Office(Dubai,UAE): +971 43261893

mobisoft

 


Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

Alias name: root
Creation date: Sep 6, 2015
Entry type: trustedCertEntry

Owner: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Issuer: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
Serial number: 2b9
Valid from: Fri May 12 22:46:00 GST 2000 until: Tue May 13 03:59:00 GST 2025
Certificate fingerprints:
 MD5:  AC:B6:94:A5:9C:17:E0:D7:91:52:9B:B1:97:06:A6:E4
 SHA1: D4:DE:20:D0:5E:66:FC:53:FE:1A:50:88:2C:78:DB:28:52:CA:E4:74
 SHA256: 
16:AF:57:A9:F6:76:B0:AB:12:60:95:AA:5E:BA:DE:F2:2A:B3:11:19:D6:44:AC:95:CD:4B:93:DB:F3:F2:6A:EB
 Signature algorithm name: SHA1withRSA
 Version: 3

Extensions: 

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:3
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
: E5 9D 59 30 82 47 58 CC   AC FA 08 54 36 86 7B 3A  ..Y0.GXT6..:
0010: B5 04 4D F0..M.
]
]



***
***


Alias name: mobile
Creation date: Sep 6, 2015
Entry type: trustedCertEntry

Owner: CN=mobile.weyak.ae, OU=Marketing, O=Etisalat, L=Abu Dhabi, ST=Abu Dhabi, 
C=AE
Issuer: CN=Cybertrust Public SureServer SV CA, O=Cybertrust Inc
Serial number: 1014ede39d478814690
Valid from: Thu Jul 30 13:10:10 GST 2015 until: Sat 

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
>> Are you using AJP or HTTP as your proxy protocol? If AJP, are
>> you using tomcatAuthentication="false" on your ? I'm
>> not exactly sure what happens when you do that... you might get
>> a NonLoginAuthenticator.
> 
> in our Vhost file, we have this:
> 
>  ProxyPass ajp://127.0.0.1:8009/xmlui
> retry=1 keepalive=on ProxyPassReverse  ajp://127.0.0.1:8009/xmlui 
> ShibUseHeaders On SetEnv proxy-sendchunked 1 
> 
> in our server.xml file, we have this:   port="8009" enableLookups="false" redirectPort="8080"
> protocol="AJP/1.3" address="127.0.0.1"
> tomcatAuthentication="false" maxSwallowSize="-1" 
> connectionTimeout="1232000" disableUploadTimeout="false"
> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
> 
> So, we're using tomcatAuthentication="false"
> 
> I will try your suggestion of using NonLoginAuthenticator and see
> what I get. If it doesn't work, I'll try your suggestion of setting
> a breakpoint and using a debugger to look at the stack.

Any luck?

You don't have to use a debugger to get a stack trace: just create a
JSP and have it 'throw Exception("getting a stack trace")'.

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

iQIcBAEBCAAGBQJV8DLwAAoJEBzwKT+lPKRY48YQAIUdyi1UwJTtdmjJBRWLXH7Q
ochdn2fBkBF+nDn1V3mLp7svDrk4SNFdymRUudOgCg4ZF4GHVClYDEVcQFMYKgOB
7NjBNtxTLXKhX7AloY+nYHJaCBEcKsYW3fZXCmNt1/KKCXq2cEcJ264++VUN//sT
khvWjTipOuDQAZYauWfQWb2T4flp5Viitq37zyYpeTD1HeTxepdTFAlPIquFYAlK
bHQQuWpI55YjTTBoDq3+FKabH97DQ1A3mLYcktIvIT4KiHFFlE2F+mb30F60Qdw7
RRDFJhTFGbnr0gIIV1b6VUJyDhh6m4bIXkRCixo41d9JAzzcmkpivaEClO+YTFwF
X8nVRPFkRiFKgKU6Gw0g/fzMNz53LrhW5TPvy7nHe2f+Ahip0M94pS3sD0azh+y0
ZoxG9JyquDQWHPGgwfQqjtide7+u5bo8mEhuUC2tWNl7iSwB7rUFgz9GgyWl7fNi
jRRZ3gCrqaZFdUoJdh9/eUpfzo24DNEPO5mNsD5Ii0REXXGHkalVd1Rk6MyYFc+X
Jt4ZJVG2Jxlcu3Z2G9wUfNBuc/0ejsmHuOKlLeg0++J0QIoKOwZw67k5HD/XoUhT
ieSV9f2LZwA5Wh3vA4o80uC94SWU/4aav6D0qhB5Np6YXy7xtX/q/oGSVu6sr0XY
zg8u3mC90npBIj5b3nPQ
=kWRl
-END PGP SIGNATURE-

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

Re: [OT] Client not loading truststore or keystore

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Diarmuid,

On 9/7/15 12:29 PM, dmccrthy wrote:
> You were right. The issue was with the code our vendor supplied for
> the Tomcat client webapp making outbound HTTPS connections. This
> was not correctly overriding classes with the result that the
> truststore and keystore environment settings were being completely
> ignored.
> 
> Thanks for your patience with this. It seems our vendor was not
> paying enough attention to log files and had me convinced that the
> issue was on our side. Your findings reiterating that it had to be
> something else helped me a lot.

Glad to help. Encrypted connections with Java requires a great deal of
plumbing code and if it hasn't been done properly, it can make it
impossible to use the library in the way you want.

For instance, if you want to use a different trust store for TLS
connections than whatever -Djavax.net.ssl.trustStore is set to, and
the library doesn't support it, you are dead in the water: you have to
get the library authors to re-write the code to support it.

I had to do this a while back with my own client code and ended up
liberally borrowing methods from Apache Tomcat to do it. Whoever did
that code in the past made it very easy for me to follow in their
footsteps.

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

iQIcBAEBCAAGBQJV8DRIAAoJEBzwKT+lPKRYbdMQAJZBg3MRmcQevN8gwBiGST7K
ubFN3uyKpOva/r8cO+qG+A3CRHd6ZW4gSe6ILxqopTxTNop+/NZuQycHSa3X+Rd+
Hd6nvMWyuXNyQe7v0U4PiZwSDyBWXw406c42B8lKo8vjuzpU7RYolkM43HkgHaLY
X56BAP2IQXfjLwPcUUPl7VZF5nUTu0NtSoEqaVXeWWR11GGSw8P5u+5ZPVPo3f1l
5DwrCY3B/0d73CKbUB55Fj11QKG7rhHWYqzjVLXA87hBx1zlKSOIiu0MA2xb+IeM
qbiyyI9CwTB6UIyCIsF7PzwUGlfBWLJwrv1eqn69uemqkOCIIxoZVkV8RuHWgFv8
5sZRcYCidlgztnIL9FsCfJRvqV8IxIwTFEZGgpzlXKvgkSiHohhjSd4KZJA1itc5
01X6K2ZW7jxWE/AYBAM21G1fjijPbXE+pcAQ+p+kP0CccPrM1O4PeDOVKjrjGGSR
b9fbFG0ntW8Z4Dud/2NFvu8DwmNMZzv56kdvKD4H1G51YkTvM+jgub0koNacgnDS
XlCPLdM6ihzLYe5bqyChB6aFpchCNaI3Q1KE02bV3IWXEKtSuqLq+ZtIWiEgGUsI
mbOtq7h3OHsaHLPfB6Jgi0YXtL/ZXeWatHe0Cab4mL91H0wnWObU6+ly+tfLdC3Z
JMenJy+1Pw2eU9HutmDZ
=LRWm
-END PGP SIGNATURE-

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

Re: FW: Issue in reading SSL certificate

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hirnya,

On 9/9/15 9:49 AM, Hirnya Kaushal wrote:
> I am facing a very peculiar issue with the SSL certificate for
> Tomcat7. I am using Java 7 and Tomcat 1.7.075. and facing the below
> issue with the SSL certificate. I have followed the below steps to
> generate the certificate and apply same on server.xml.
> 
> Generated the CSR file by using the keytool on the server.
> 
> 1)  *$JAVA_HOME/bin/keytool ** -genkey -alias server -keyalg
> RSA -keysize 2048 -keystore /opt/hirnya/mobileweyakae.jks*
> 
> 2)  *$JAVA_HOME/bin/**keytool -certreq -alias server -file 
> /opt/hirnya/csr.txt -keystore /opt/hirnya/mobileweyakae.jks*

Good so far.

> Shared my case file with CA provider and received back chain.p7b
> file. And followed the below step to import the key tool (I tried 2
> ways to apply the same but the end results and the error on the
> tomcat logs are almost same.)
> 
> 1. Double click .p7b file on windows 2. Expand the node
> certificates from the left side. 3. On the right side the list of
> certificate occurred. 4. Double click the required certificate to
> open it. 5. Click the details tab. 6. Click the "copy to file...”
> button 7. click next 8. select the 2nd format (Base-64 encoded
> X.509 (.CER)) 9. Enter the file name (As original file name).
> Please make sure the file location (Directory) 10. Read the export
> wizard setting and then Press "Finish" button. 11. Repeat the same
> steps for all 3 certificates.
> 
> Then, transferred the all certificate on same path where I have 
> generated the csr file and imported the file with 2 different way.
> 
> 
> 
> Steps of Process one applied:
> 
> Imported the files received from CA with below command and applied
> with all files received from CA.
> 
> *$JAVA_HOME/bin/keytool -import -trustcacerts -alias root -file 
> /opt/hirnya/root.cer -keystore /opt/hirnya/mobileweyakae.jks*

You might want to call this "Cybertrust root" or something like that,
in case you want to use more than one CA's root. It also helps
document what *you* think the certificate is.

> *$JAVA_HOME/bin/keytool -import -trustcacerts -alias abc -file 
> /opt/hirnya/server.cer -keystore /opt/hirnya/mobileweyakae.jks*

An alias like "Cybertrust intermediate" might have been a better name.

> *$JAVA_HOME/bin/keytool -import -trustcacerts -alias mobile -file 
> /opt/hirnya/mobile.cer -keystore /opt/hirnya/mobileweyakae.jks*

I see that you haven't imported any certificates with the alias
"server". When you import the signed certificate from the CA, you
should probably update the "server" cert instead of importing it under
a different alias. This may not be the problem, but it's the way I've
always done it.

> *Attached is the view of certificate generated
> (crtifacate-process1.txt) and the tomcat logs ()tomcatand below is
> the configuration for SSL on tomcat.*

Looks okay to me. There are 4 certs:

1. root   (Cybertrust's root cert)
2. mobile (your signed server certificate)
3. abc(Cybertrust's intermediate certificate)
4. server (the private key for the cert you want to create)

> * protocol="org.apache.coyote.http11.Http11Protocol"
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> clientAuth="false" sslProtocol="TLS"  useURIValidationHack="false" 
> keystoreFile="/opt/hirnya/mobileweyakae.jks"
> keystorePass="changeit" />*

You haven't specified an "alias" for the connector, so it uses the
first one in the keystore which is probably "root". That's not what
you want.

> Steps of Process Two applied:
> 
> Exported the keystore to the pem file.
> 
> 
> 
> *1)  **$JAVA_HOME/bin/*keytool -exportcert -rfc -file 
> /opt/hirnya/server.pem -keystore /opt/hirnya/mobileweyakae.jks
> -alias server
> 
> *2)  **Open the pem file with cat and added the other
> certificates received from CA into the same file and generated the
> bundle.pem file, attached is the file for reference. (this includes
> all the certificates)*
> 
> *3)  **Then imported the certificates to the keytool with below
> command*
> 
> *$JAVA_HOME/bin*/keytool -importcert -keystore 
> /opt/hirnya/mobileweyakae.jks -alias server -file
> /opt/hirnya/bundle.pem.
> 
> 
> 
> 
> 
> The certificate generated output is attached as
> certificate-process2.txt for reference and the logs of the tomcat
> as well.
> 
> * *
> 
> * *
> 
> In both the case I am able to reach the https:// but receiving the 
> security error and only reading the self-generated key and not able
> to read the imported key.

What is showing the error? The browser or Tomcat (or both)? Any stack
traces from Tomcat?

> Attaching the generated key files(mobileweyakae.jks) and
> certificate (hirnya.zip) as well for your reference.

If you did in fact attach your Java keystore, then you have leaked
your server's private key and it can no longer be considered secure.
You ought to delete everything and start over again. BEFORE YOU DO,
confirm that your CA will re-sign a new CSR with a 

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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shi,

On 9/9/15 10: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.
> 
> 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?

So, the *client's* DNS has been hijacked? The only thing you can
really do about that is require your users to use DNSSec or something
like that... not sure if that's even possible.

You could require HTTPS for everything and request certificate
pinning, but again there are ways around that.

You may not be able to do anything other than contact some authority
and try to get the rogue site shut down.

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

iQIcBAEBCAAGBQJV8E4vAAoJEBzwKT+lPKRY5lkP/j6nfHoEydxcqbKeZxM7jVHG
/jxFbTdbt4qATsRj50IyEaZF2wTfhq17O1pfUQWa1zqXPxehJobl0otNmOTjoOwB
R5y3C5EUQPS8Umox1Tw+3liEDPDrOesqSPBm7XrvbS5u3kukOqBLC61KJgzsgDAu
YTqrMjODNffa7qIHOFSn6Wjy0R0dVVGa5RcxJ9f+Et7DPbHdtVa4Y7zXiltrVFBg
BHwTVSxCv8QrfTmSZgEJ819v+UZrh8lmytHnXsF4tkBvxubEEiKS3lDwTucrR/jl
mTbQDgEjra88heRl1cAU8xDVoy7y29TEZXlZcLzXG84BoAH82fOhFfo3PcMx0YI1
1W0zqCyuu7BYfgbkbtqRL76h2Nj7XPBL0qS3FmxctjZNLPAvs+2KUadkU6ecK0/6
ELnXJDZz6VzAm+cEr4Wynah42EGXBEq6y32t1Iv/s5WGv0CYmM7+TByE/s24ozzr
2BucnH1kH/3v8m5Dn6/MGpCkzaCT5+mJCR7da6nyzDN/Rupu+JAjjkj1jXjLkVgf
2EnKhN52t+Rdl+0UwV/e9qoPJgWQfBcpLQ6SkyD5h/L+SI6OPVMvHtT9w7py0EJf
LOdSAqSYt8a5CcICJFOKjip0O5icMqIwr4kwwFS0oKuUk1g8EfuiDjMlxylbLYvL
sU7+8Aa6cdyB1N+p38z7
=J+8s
-END PGP SIGNATURE-

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

Re: Undefined behaviour with Credential Handler

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8E9cAAoJEBzwKT+lPKRYvFUQAJOnonwIc7wdMKSbyn6ldsXT
+2A1gC16QpAnvWgP8RkqDgDn9zPfYBfdRePpI3voDxNJsiKxSuqPhldlPTtyu+28
4KWDifi1qxTbhvMasSv1AgwkzMjOBFWitZ8NLbr4AUK/m878Goc0nSUEDIirpLNq
THfQAL5fvN0IXl6IqDx5dEyGekBQsSg6Q1NqU5ZL6w2GLvhwYBfTE/eFsHzw/mc2
Z7IIC/gt7wT4FbkzzMF1Qcp6TKvEA1pdLU0KCcE7BiLCiwJxWfQTCI2WWEJIMV2s
FwkvLDXidqmNIL6Wg4QoaB093lw5UcQY0r2kUtCL4gkuS7IqCyLeFaaJFXoN2iY9
+OlLlPF1DrsKAhJejDuge1+ixksWDd3VqL6DoMHqldpG5kh1CIPjO3Cwpnw5ypNX
/v5u4dq318qrcp2UGsr/1mRXx0t7gNUfgqGqS+4wDw40TekGJbGJqhFaVoq82sjz
gFPOhjTeSDExb0zTiyhaRus4VtqlGUnMj+CIx+4yMDg1ax/Le19yV7if+p4KRaB+
Ua+D31QY5sz09CIJIog9WOiQ20PGDsWSgQzKevoqZCDgWfx/NChG5rz0ku0DdHsC
nednB/m8TGrT6ziT33NIbfDGgp31egkI6TjqVcLaK4IX1L073R83sQ9O6m5pqmJ+
t5YGoYKn1OMac388Rx7N
=Ha10
-END PGP SIGNATURE-

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

Re: Unable to get the jmx information for tomcat 8 from command line(curl command)

[Neven Cvetkovic]

On 9 Sep 2015 17:59, "Christopher Schultz" 
wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Andrew,
>
> On 9/8/15 9:21 AM, Andrew M wrote:
> > Any idea why it is saying "401 Unauthorized"
>
> > I execute the following command: curl -1 --max-time 10 -s -k -u
> > tomcat_jmx:'eyFW$&$FvSIp#FUk' --url
> > https://pentagon505:8443/deploy/jmxproxy?
>
> Your shell may do something odd with a partially-quoted
> username/password argument. Try this:
>
> $ curl -1 --max-time 10 -s -k \
> -u 'tomcat_jmx:eyFW$&$FvSIp#FUk' \
>  --url https://pentagon505:8443/deploy/jmxproxy?
>

Can you post your  information? Your password does not match. You
did not provide proper user/pass combination, i.e. did not properly
authenticate, hence 401 error.

> > I have added the user to tomcat-users.xml configuration file as
> > well> password="pass1!" roles="manager-gui"/>> rolename="manager-jmx"/>   > password="passwords!@#" roles="manager-jmx"/>
>

> The #1 error with tomcat-users.xml is forgetting to un-comment the
> block of XML.
>
> > Please note that I am executing the command from a remote server:
>
> > Complete output is as follows: > HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd;>
> >  401 Unauthorized  
> >    401
> > Unauthorized   You are not authorized to view this
> > page. If you have not changedany configuration files, please
> > examine the fileconf/tomcat-users.xml in your
> > installation.
>
> That sure looks like a failure to authenticate, coming from Tomcat.
>

+1

Re: Errors at INFO level despite "Note: further occurrences of ... errors will be logged at DEBUG level."

[Robert Tupelo-Schneck]

> On 2015-08-20, at 06:03, Konstantin Kolinko  wrote:
> 2015-08-19 18:21 GMT+03:00 Robert Tupelo-Schneck :
>> I'm running Tomcat 8.0.24.  I see lots of errors in catalina.out with lines 
>> like
>> 
>> Note: further occurrences of Cookie errors will be logged at DEBUG level.
>> Note: further occurrences of Parameter errors will be logged at DEBUG level.
>> Note: further occurrences of HTTP header parsing errors will be logged at 
>> DEBUG level.
>> 
>> But, the errors keep showing up at INFO level!
>> 
>> I get these many many times a day, but I do not get user complaints, and I 
>> have not been able to cause the errors myself.
>> 
>> I would like to either
>> (1) Make these errors go away (such as by really having them logged at DEBUG 
>> level), or
>> (2) Get detailed information on the client request that caused the error so 
>> I can figure out how to make them less frequent.
> 
> 1. Both logging level and silencing interval are configurable with
> system properties. See properties with "UserDataHelper" in their name
> on the following page:
> 
> http://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Logging
[...]
> It is possible to change cookie handling by configuring a different
> CookieProcessor,
> http://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html

In case others experience similar issues, I wanted to record that what worked 
for me was to add this line to conf/catalina.properties:

org.apache.juli.logging.UserDataHelper.CONFIG=DEBUG_ALL

and this line to conf/context.xml:



Now my logs are free from these unwanted messages.

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

Re: ServletRequest.getRemoteHost() not working when Tomcat is behind Nginx (Nginx as a reverse proxy)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 9/8/15 5:16 PM, Brian wrote:
> mm.. ... Well, so far I have always assumed that Tomcat
> itself has always made this effort (assuming that it is enabled to
> do so in the connector), so that when I execute the method I'm just
> retrieving the value. I'm I wrong?
> 
> In this case when using Nginx+Tomcat, I assume that Nginx already 
> made the effort to get the remoteHost value as well, so Tomcat
> just receives it and I just need to invoke the method to get it.
> Maybe I'm wrong here.

You have to enable the RemoteIPValve, which was specifically written
for this purpose:

http://tomcat.apache.org/tomcat-8.0-doc/config/valve.html#Proxies_Suppor
t

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

iQIcBAEBCAAGBQJV8FU6AAoJEBzwKT+lPKRYhC0QALJWX08e7xiC85YFsUgm5Kn9
YLGtsJCwlRJLZKsJuI/5/a6d0LiQdCfhmNmZO+uk9uyzo2MSJchVcPOJzJ1EsDVx
Yu0U3TRV3FFkecJyEaIjkTJCAufR2tcV0KdUK1tCJ7KfLrLebwneVaIzfw1T/DM4
xW8fkAvCgueEyTteEVc9fUPc7ck/5+jEXV8DrFXE51gISJea79BWfTd5V/FTjK/D
kgteoRbPoLxlRnhUTaeAyT7qxbEiNX5hjZ498NsBOgZ4/qk+EkdVFXK9QdJ0drsP
FhvahJE19VtVuxFnI9EOfg/yiH+ZwE1xygfgZfYQ9SyyaUgIAWYXzLOUrlHUdVES
jprwk3UFcxDrv+fAkhFefHQDk2LdgPDm7/ZeYvU+cKbd17gPHkLfcl9cX75v5pk5
yDi+wnSjZY1sMHlglbwhJGfCtttRTkbV+isTKkL5DeU2+IJPZU2/K3/1d0iVygXv
bPf58cWjdas/1C+9IcWl8zRZjMv3iunzN92McdPwVkt3OR1izFiGAaB/qByzHGLA
IvkqEdcSdpgED34jDHRWtNkgnW17p628IbUL7PBsG/e+BPKSsRfM4cxkBZw8CUPj
jLdDEH8ENYcEBtids+baHdkWsdsRld5h8VwifaA935RB2NnGb2vyk8S1YqQa3gh5
g3QRGpgjesJBn+H7+DHd
=2AhX
-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: 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?
Jeff

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

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

[shi]

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.

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

Re: Unable to get the jmx information for tomcat 8 from command line(curl command)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andrew,

On 9/8/15 9:21 AM, Andrew M wrote:
> Any idea why it is saying "401 Unauthorized"

> I execute the following command: curl -1 --max-time 10 -s -k -u 
> tomcat_jmx:'eyFW$&$FvSIp#FUk' --url 
> https://pentagon505:8443/deploy/jmxproxy?

Your shell may do something odd with a partially-quoted
username/password argument. Try this:

$ curl -1 --max-time 10 -s -k \
-u 'tomcat_jmx:eyFW$&$FvSIp#FUk' \
 --url https://pentagon505:8443/deploy/jmxproxy?

> I have added the user to tomcat-users.xml configuration file as
> wellpassword="pass1!" roles="manager-gui"/>rolename="manager-jmx"/>   password="passwords!@#" roles="manager-jmx"/>

The #1 error with tomcat-users.xml is forgetting to un-comment the
block of XML.

> Please note that I am executing the command from a remote server:

> Complete output is as follows: HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd;>
>  401 Unauthorized  
>    401 
> Unauthorized   You are not authorized to view this
> page. If you have not changedany configuration files, please
> examine the fileconf/tomcat-users.xml in your
> installation.

That sure looks like a failure to authenticate, coming from Tomcat.

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

iQIcBAEBCAAGBQJV8Fc0AAoJEBzwKT+lPKRYxQsP/0zPdIrgunYxBlRX13qZSC2X
lokaa68oi49wsLyMrHW/H8E2fBpdkkiqnHEF2r9OPSyfFzE39+iXOk3lnEajOpvg
YZmGNEdVb+OrOY3apg9t5EZbviCbGJPvYRvC+peR8Gv0z/6ty9SpDAqinROOZxhk
QiH38bIA43bsJzbxKKPYeedSv2FAq8tKccuvZ6P76Nob5Q/ye/JLSxQJTvOjdZ4j
lVkegjw9W4a6ZkByUQUJmBtuyUUQWpBX3jzvtlI3mZcxmR8/9nTBzdHUGNMRxACH
kKJx19t1k3mjRHCYQrU9hY7GdZjl26pARsDk3FxHvr155Mx+T2iKOD6FZMetgxoj
uf5wkh2MsqbV1X2BFrYMiYJGk5NRgQr81UHEuhE66R82zJ9q9b3/O4v0S+cz78Wg
/sZN/d9+s4IT7CWFbzOVYvDKc6Al0pu+LAFCx+Crpt+kdZgXEnEYGDOsqExNjV7b
aZJdwlViJzZ16E6oOX94aU+NtTiipIAyAXC6UxoHqWCvj20Xeby+ajWcVstJ9WTj
QXtFUyx8KtE3Zp+60k6Ematcl9IhEkMXR/GfWDURnZewXn870gqejAyns9dKw6E7
x1r8G6/YJJIsyTKTu5ju9enkjLyWfbW0JtfpspcWfLeDqC2rG8bWe4JBQBqX6yGM
UgCMMInuEYOHynWjeLpE
=ctld
-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

[Mark Thomas]

On 09/09/2015 21:30, Christopher Schultz wrote:
> Hardy,
> 
> On 9/9/15 4:22 PM, Pottinger, Hardy J. wrote:
>> Ha, sorry for the useless detail :-)
> 
> It's no problem. Stymied by the effective use of class extension
> features in an OO language. :)
> 
 Is that enough of a clue?
>>> Ha ha ha, no unfortunately not: pretty much all of the
>>> authenticators extend from AuthenticatorBase, so the only thing
>>> it tells us is that there is at least *some* authenticator.
>>>
>>> If nobody else replies, I'll try to trace-through the code to
>>> figure out what kind of authenticator you are getting. I'm
>>> guessing NoLoginAuthenticator is the one, though.
> 
>> Thanks for the offer of tracing through the code. If you're really
>> interested, here is a starting point: 
>> https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/
> org/dspace/authenticate
> 
> Yeah,
> 
> I'm not looking-through that. I was going to look at Tomcat's
> source, which should be as far as I'll have to look.
> 
> Or, if one of the other committers with more experience with this code
> (*cough*markt/kkolinko*cough*) could comment, it would save me a bunch
> of time ;)

But you'd learn so much ... ;)

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.

HTH,

Mark

-
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.]

Oh, yeah, duh, I will look at the Tomcat source, too. Thanks!

Sent from my Zact Mobile phone.

Christopher Schultz  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/9/15 4:22 PM, Pottinger, Hardy J. wrote:
> Ha, sorry for the useless detail :-)

It's no problem. Stymied by the effective use of class extension
features in an OO language. :)

>>> Is that enough of a clue?
>> Ha ha ha, no unfortunately not: pretty much all of the
>> authenticators extend from AuthenticatorBase, so the only thing
>> it tells us is that there is at least *some* authenticator.
>>
>> If nobody else replies, I'll try to trace-through the code to
>> figure out what kind of authenticator you are getting. I'm
>> guessing NoLoginAuthenticator is the one, though.
>
> Thanks for the offer of tracing through the code. If you're really
> interested, here is a starting point:
> https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/
org/dspace/authenticate

Yeah,
>
I'm not looking-through that. I was going to look at Tomcat's
source, which should be as far as I'll have to look.

Or, if one of the other committers with more experience with this code
(*cough*markt/kkolinko*cough*) could comment, it would save me a bunch
of time ;)

- -chris

>  From: Christopher Schultz
> [ch...@christopherschultz.net] Sent: Wednesday, September 09, 2015
> 3:09 PM To: Tomcat Users List Subject: Re: seeking help with
> stabilizing the persistence of a JSESSIONID
>
> Hardy,
>
> On 9/9/15 3:54 PM, Pottinger, Hardy J. wrote:
>> Well... it occurred to me that from time to time we happen to
>> have stack traces show up in our log files due to some error or
>> another, and, I could just *look* at the log files. Sure enough,
>> here's an example of one line of interest (there are many similar
>> ones):
>
>> at
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
t
>
>>
orBase.java:503)
>
>> Is that enough of a clue?
>
> Ha ha ha, no unfortunately not: pretty much all of the
> authenticators extend from AuthenticatorBase, so the only thing it
> tells us is that there is at least *some* authenticator.
>
> If nobody else replies, I'll try to trace-through the code to
> figure out what kind of authenticator you are getting. I'm
> guessing NoLoginAuthenticator is the one, though.
>
> -chris
>
>> From: Pottinger, Hardy J. Sent: Wednesday, September 09, 2015
>> 9:35 AM To: Tomcat Users List Subject: RE: seeking help with
>> stabilizing the persistence of a JSESSIONID
>
>> Hi, thanks for following up! No, no luck at all. The web
>> application I'm working with is based on Apache Cocoon 2.2, so,
>> no JSPs in sight. I am actually weighing my options, I have a
>> choice to either pursue making the current design work (i.e. try
>> to get the session to stick around long enough so I can use it),
>> or else change the design and go with a more conventional "pass
>> the return URL around as a parameter in the request" approach.
>> I'm leaning towards the latter, as it sidesteps this whole issue
>> we're having with session fixation protection, *and* it deals
>> with a slightly esoteric use case, where a user encounters a
>> password challenge when attempting to view a restricted item,
>> backtracks, then later chooses to log in for some other reason,
>> and is returned to the original restricted item page (because the
>> redirect URL is still in the session).
>
>> If I do continue to persue the session route, I'll let you know
>> if I'm able to determine what authentication class ends up in
>> the stack trace.
>
>> --Hardy  From:
>> Christopher Schultz [ch...@christopherschultz.net] Sent:
>> Wednesday, September 09, 2015 8:24 AM To: Tomcat Users List
>> Subject: Re: seeking help with stabilizing the persistence of a
>> JSESSIONID
>
>> Hardy,
>
>> On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
 Are you using AJP or HTTP as your proxy protocol? If AJP,
 are you using tomcatAuthentication="false" on your
 ? I'm not exactly sure what happens when you do
 that... you might get a NonLoginAuthenticator.
>
>>> in our Vhost file, we have this:
>
>>>  ProxyPass
>>> ajp://127.0.0.1:8009/xmlui retry=1 keepalive=on
>>> ProxyPassReverse ajp://127.0.0.1:8009/xmlui ShibUseHeaders On
>>> SetEnv proxy-sendchunked 1 
>
>>> in our server.xml file, we have this:  >> port="8009" enableLookups="false" redirectPort="8080"
>>> protocol="AJP/1.3" address="127.0.0.1"
>>> tomcatAuthentication="false" maxSwallowSize="-1"
>>> connectionTimeout="1232000" disableUploadTimeout="false"
>>> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
>
>>> So, we're using tomcatAuthentication="false"
>
>>> I will try your suggestion of using NonLoginAuthenticator and
>>> see what I get. If it doesn't work, I'll try your suggestion
>>> of setting a breakpoint and using a debugger to look at the
>>> stack.
>
>> Any luck?
>
>> You don't have 

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

[shi]

Hi gurus,

Do you have some good suggestions/solutions for my issues?


Thanks,



At 2015-09-09 22:46:56, "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.

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





 

Re: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

Here is the web.xml for the main UI webapp
https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/webapp/WEB-INF/web.xml
Sent from my Zact Mobile phone.

Mark Thomas  wrote:


On 09/09/2015 21:30, Christopher Schultz wrote:
> Hardy,
>
> On 9/9/15 4:22 PM, Pottinger, Hardy J. wrote:
>> Ha, sorry for the useless detail :-)
>
> It's no problem. Stymied by the effective use of class extension
> features in an OO language. :)
>
 Is that enough of a clue?
>>> Ha ha ha, no unfortunately not: pretty much all of the
>>> authenticators extend from AuthenticatorBase, so the only thing
>>> it tells us is that there is at least *some* authenticator.
>>>
>>> If nobody else replies, I'll try to trace-through the code to
>>> figure out what kind of authenticator you are getting. I'm
>>> guessing NoLoginAuthenticator is the one, though.
>
>> Thanks for the offer of tracing through the code. If you're really
>> interested, here is a starting point:
>> https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/
> org/dspace/authenticate
>
> Yeah,
>
> I'm not looking-through that. I was going to look at Tomcat's
> source, which should be as far as I'll have to look.
>
> Or, if one of the other committers with more experience with this code
> (*cough*markt/kkolinko*cough*) could comment, it would save me a bunch
> of time ;)

But you'd learn so much ... ;)

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.

HTH,

Mark

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


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

I'm searching for a parser of JSP

[八反田 香莉]

Hello,

I want to make the JSP code analysis tool. I'm looking for a parser for that
For example , when I write a JSP source code using Eclipse,
it's tool can check if there is any specific description.
But , there is no appropriate parser of JSP that can be used for such
purposes .I require as possible ready-to-use parser tree of JSP.
Can I use parser of Jaspar for such a purpose ?

Best Regards
Kaori

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

Re: I'm searching for a parser of JSP

[Mark Lovatt]

Hi Kaori

I don't know a parser for traditional jsp but if you use jspx then you can use 
any xml parser or the JspDocumentParser provided by Apache.

Kind regards

Mark Lovatt
markmlov...@gmail.com
uk.linkedin.com/in/mmlovatt

Sent from my iPhone

> On 10 Sep 2015, at 06:25, 八反田 香莉  wrote:
> 
> Hello,
> 
> I want to make the JSP code analysis tool. I'm looking for a parser for that
> For example , when I write a JSP source code using Eclipse,
> it's tool can check if there is any specific description.
> But , there is no appropriate parser of JSP that can be used for such
> purposes .I require as possible ready-to-use parser tree of JSP.
> Can I use parser of Jaspar for such a purpose ?
> 
> Best Regards
> Kaori
> 
> -
> 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/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
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8H9WAAoJEBzwKT+lPKRYUrUP/jFofb1kyXtipLisOXrDRKRi
dXgapMR+XsBMUNBqQOCbwM1YRn2IV9+pF2oJaLtN/R36rweoYMywvbqc6LWG+MuL
oOu8Qe7t5RRXVbOdvP5hYPTNiVDNGPYSmPHg5gbGsPNfhUWqMNutWbQBxZwjX+kH
Q0P71bgk2Nf4Ch0wqjQImCsO+oQH2BeHUOCC7FLYsRa8r8nS8Ml0MXmvQl57yZzB
cUm/V4Z1ygh8QxvB2ZmIber2KFVx4gJyZh6usTnpkb0lm7x1H0PUylpklyYSTJKv
thR3DSgVjLe582I8/2/rIjpGhqqP/TUAv9INh7WprzLGTb4wQQRKkPYAwy/9vxhI
4+PDs6qTalS9iti8GdA5MIg6CuK55Gu26rvlC+FNSsYQMMMzedySTri1tJQgCkJd
JQL97eoouNFd3K06EuCyUWIoOfGqCNNoYpDYaxN/IeBwbefSR8mUctWsWKDdX6MJ
p7/I3saRu3na8oLR4nnZz8a/I/oIQWwvJebHMN3UFuSgBLxIwgurE6LHZ8tSP2YP
D/QYKSnY+KoGb7tPR4O0FTxr7EULUFtVgWPCy6WePi1jkVxqmKPD3rIU+TtPzwLb
QDiI4W4O3lL97F1iZNcjNGnbDgpOcJdhJjORFQl/KEX8r6D9fN0h0LjgSuuEJnr7
JrNmcEq8wsZxM1VgxtRn
=ZL2V
-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.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeffrey,

On 9/4/15 4:40 PM, Jeffrey Janner wrote:
> I'm surprised that Tomcat would use the "wrong" session id for 
> URL-rewriting when presenting the login screen. Are you saying
> that, when showing the login page for /APP2, Tomcat will:
> 
> a. Place a session identifier in the URL with value X b. Return a
> Set-Cookie response header for JSESSIONID with value Y
> 
> Where X != Y?
>> So far, it looks like it is maintaining an X=Y philosophy. So
>> that's a non-starter.

Maybe we aren't communicating well: I'd expect to see X = Y *100% of
the time*. The session id for both the URL *and* the cookie should be
the same, otherwise mass confusion would ensue.

> But you do use Tomcat's session-tracking mechanisms, right?
> 
>> Yes, and the problem only rears its ugly head on a successful
>> login (app expires old cookie, creates a new one).

Usually, Tomcat won't explicitly expire an old JSESSIONID cookie...
just set another one with a new value. The browser should replace the
old value with the new one.

>> User never even sees a new page, just an app-generated "session 
>> expired" error. Trying to see things in access logs, but nothing 
>> there I can see.

Hmm.

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

iQIcBAEBCAAGBQJV8H7uAAoJEBzwKT+lPKRYf30QAJ6V2G22zeRhRS7pl3rkhk7w
4/de4gpP+HfS/TYdOrLWr/qn26VPM38xjqPTuOvLTTGNfqgTdKhhrpQwEtHA9iSj
9K3oFmoEN7vXxshKjp2Q5bmjKemez1NVX43bwolq8+fTjVSlGZwTZcSA8+n2rJ05
vV5mBT+O4iqdYT1L1zdUj8XGWBS7hDmL9XCJM+08c4Rxajin37J4Xebi1HBAIM5a
WLijOUNAGHnkfDfpipxBgRcPly/wj//D0TdAZRMLqjVBh3DN6Lxhi59IOIiQgOYc
vu7l+GsimC1QI9/qM88JYlOXzJqpncjdYddyiJXdjvs1b7Rqk2QFGNyzE+njtPYK
icatILkejaN4Ic73mZZtHck50uY7vUagoZCAgsi48vMxsNXraFqrsN6NlKVVI3RN
L11+z7+qftoirWKGgTFmADikm/sknYiaezaVRIYLJohADONeQQ0sd9NpR4LQOU1x
87kWL+6rNfhNrnsWlGpm9PiBY4ZhmfpTcgK5iIJG3/2teCpk6sjye0BuVxkgQUPd
cHiTrhZgEVfkroWLTt55pKvIJmpX6BMA0R43UOk6NwTUrc0oKVqnZvkTMxt95b0m
lhHTRGFloCK3vKpz6ebeKowLz0Pc9rRBn6sQAANZgPd67m8XGjUDZ5lNBuz7XH/D
SfggjrqFB4x52K+EDETR
=LgVZ
-END PGP SIGNATURE-

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

Re: HTTP 400 with Form based authentication

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sreyan,

On 9/9/15 12:49 PM, Sreyan Chakravarty wrote:
> Okay can you please guide me on how to log the bug. That would be
> great. If possible you could do it yourself also.

1. Register for Bugzilla at bz.apache.org
2. Fill-out this form:
   https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
   (You can get here from inside BZ, of course, but here's the link
just in case you need it.)
3. Take care to describe this as best as you can. Feel free to
   reference this thread on the list; links to things like markmail.org
   are great because readers can easily follow them to get the
   context of the discussion, even if it's not fully contained in the
   bug report
4. If you're up for it, propose a patch. You'll get your name into the
   changelog for all eternity :)

> And as far as opinions go I really don't know. The whole process of
> Realms seem confusing to me and its overtly complicated.

Presumably you mean "overly complicated". It's actually not once you
understand the complexity of what's being implemented. The
Authenticator/Realm split exists because any combination of
authentication mechanism (HTTP Basic, HTTP Digest, FORM, TLS-CERT,
etc.) and credential-storage mechanism (e.g. JDBC database, Java
Truststore, flat-file, etc.) needs to be supported.

I've always thought that the names (authenticator and realm) were bad
and confusing (especially because HTTP Basic/Digest uses the term
"realm" to describe the general thing-to-which-you-are-authenticating).

Perhaps better names would be:

authenticator = credential soliciter
realm = credential validator

But these names are far too historic to change, now.

The good news now is that the realms support better than the least
effort possible for a security system. The best you could do a year
ago was to use a single run-through of a supported hash algorithm, and
the default was MD5. Yuck. So, the fact that you can plug-in your own
algorithms for credential mutation is a really great system. To
wire-in scrypt a year ago would have been a mess, unless you just
wanted to write your own Realm that only supported a single authenticato
r.

Anyhow, things are getting better thank to contributions from the
community. Welcome to the community :)

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

iQIcBAEBCAAGBQJV8JYgAAoJEBzwKT+lPKRYIoAP/0ibxPVquauuMJK/qf05H+iy
pUpfplwh1U0WyzhC/B1V2NV7WIxf5QzaX4ld/3EJUu7yZLujA7qRrhMVN+WsCoKw
KghKyXgaLq0kWXQMXn1Aoe/9hiG32XQA59aR3Um+i8fNBv66aoIMj7albHeVFhTG
Dzf3QJAgjU3EKB4vxf+UKomfJkbr4SBOo12NXcQ37Pb5TPgFeHX//5RJBe0xS3Uh
XD+OSYDWi0gMOJfJK5bTar0gpSumzeOu+mX7iPJ6j7QLX1z73bcwG0WTRU0KRqlO
BQjZMe7qLL4Q+G4cbN4UV1lRdO7NYQ7IStHV8r05orY6BZmglaLKTEOHaqRKw2MQ
coaMArpu9eZOz0PN8HdhPT4u6N4EpYlahDZgqrY8hQlwGjatQHGAzdWeQ0i0Mmr+
BnVZT6vozA1d0tx8OUdmyWucgVy252s5iwCa9SZiaMpjugQbEpX9tYu8EQVQREZy
1UWrKcIlOGJ5be1iPWHq1yk6MEdAMDffHvhZdgzCshtzMy/tJ+VgntSjUzsJnu16
TmnlOgcWr5B/DK/ixH6BriHr4fWMLZAhsBR/WST5zgO/4CP0eZeoAGjma5B6V3pJ
Dcw3WvSpgq6dxbHJu8UxFjX3h6bwAEpLtyFo1fH2LwIfzkLN4UEikq7Rxfmcg9K/
j2lu4amIXCn5pmxzahH7
=Ux0j
-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/9/15 4:22 PM, Pottinger, Hardy J. wrote:
> Ha, sorry for the useless detail :-)

It's no problem. Stymied by the effective use of class extension
features in an OO language. :)

>>> Is that enough of a clue?
>> Ha ha ha, no unfortunately not: pretty much all of the
>> authenticators extend from AuthenticatorBase, so the only thing
>> it tells us is that there is at least *some* authenticator.
>> 
>> If nobody else replies, I'll try to trace-through the code to
>> figure out what kind of authenticator you are getting. I'm
>> guessing NoLoginAuthenticator is the one, though.
> 
> Thanks for the offer of tracing through the code. If you're really
> interested, here is a starting point: 
> https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/
org/dspace/authenticate

Yeah,
> 
I'm not looking-through that. I was going to look at Tomcat's
source, which should be as far as I'll have to look.

Or, if one of the other committers with more experience with this code
(*cough*markt/kkolinko*cough*) could comment, it would save me a bunch
of time ;)

- -chris

>  From: Christopher Schultz
> [ch...@christopherschultz.net] Sent: Wednesday, September 09, 2015
> 3:09 PM To: Tomcat Users List Subject: Re: seeking help with
> stabilizing the persistence of a JSESSIONID
> 
> Hardy,
> 
> On 9/9/15 3:54 PM, Pottinger, Hardy J. wrote:
>> Well... it occurred to me that from time to time we happen to
>> have stack traces show up in our log files due to some error or
>> another, and, I could just *look* at the log files. Sure enough,
>> here's an example of one line of interest (there are many similar
>> ones):
> 
>> at 
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
t
>
>> 
orBase.java:503)
> 
>> Is that enough of a clue?
> 
> Ha ha ha, no unfortunately not: pretty much all of the
> authenticators extend from AuthenticatorBase, so the only thing it
> tells us is that there is at least *some* authenticator.
> 
> If nobody else replies, I'll try to trace-through the code to
> figure out what kind of authenticator you are getting. I'm
> guessing NoLoginAuthenticator is the one, though.
> 
> -chris
> 
>> From: Pottinger, Hardy J. Sent: Wednesday, September 09, 2015
>> 9:35 AM To: Tomcat Users List Subject: RE: seeking help with
>> stabilizing the persistence of a JSESSIONID
> 
>> Hi, thanks for following up! No, no luck at all. The web 
>> application I'm working with is based on Apache Cocoon 2.2, so,
>> no JSPs in sight. I am actually weighing my options, I have a
>> choice to either pursue making the current design work (i.e. try
>> to get the session to stick around long enough so I can use it),
>> or else change the design and go with a more conventional "pass
>> the return URL around as a parameter in the request" approach.
>> I'm leaning towards the latter, as it sidesteps this whole issue
>> we're having with session fixation protection, *and* it deals
>> with a slightly esoteric use case, where a user encounters a
>> password challenge when attempting to view a restricted item,
>> backtracks, then later chooses to log in for some other reason,
>> and is returned to the original restricted item page (because the
>> redirect URL is still in the session).
> 
>> If I do continue to persue the session route, I'll let you know
>> if I'm able to determine what authentication class ends up in
>> the stack trace.
> 
>> --Hardy  From:
>> Christopher Schultz [ch...@christopherschultz.net] Sent:
>> Wednesday, September 09, 2015 8:24 AM To: Tomcat Users List
>> Subject: Re: seeking help with stabilizing the persistence of a
>> JSESSIONID
> 
>> Hardy,
> 
>> On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
 Are you using AJP or HTTP as your proxy protocol? If AJP,
 are you using tomcatAuthentication="false" on your
 ? I'm not exactly sure what happens when you do
 that... you might get a NonLoginAuthenticator.
> 
>>> in our Vhost file, we have this:
> 
>>>  ProxyPass
>>> ajp://127.0.0.1:8009/xmlui retry=1 keepalive=on
>>> ProxyPassReverse ajp://127.0.0.1:8009/xmlui ShibUseHeaders On
>>> SetEnv proxy-sendchunked 1 
> 
>>> in our server.xml file, we have this:  >> port="8009" enableLookups="false" redirectPort="8080" 
>>> protocol="AJP/1.3" address="127.0.0.1" 
>>> tomcatAuthentication="false" maxSwallowSize="-1" 
>>> connectionTimeout="1232000" disableUploadTimeout="false" 
>>> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
> 
>>> So, we're using tomcatAuthentication="false"
> 
>>> I will try your suggestion of using NonLoginAuthenticator and 
>>> see what I get. If it doesn't work, I'll try your suggestion
>>> of setting a breakpoint and using a debugger to look at the
>>> stack.
> 
>> Any luck?
> 
>> You don't have to use a debugger to get a stack trace: just
>> create a JSP and have it 'throw Exception("getting a stack
>> trace")'.
> 

Re: HTTP 400 with Form based authentication

[Sreyan Chakravarty]

Okay can you please guide me on how to log the bug. That would be great. If
possible you could do it yourself also.

And as far as opinions go I really don't know. The whole process of Realms
seem confusing to me and its overtly complicated.

Thanks for testing out the issue.

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

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sreyan,
>
> On 9/9/15 9:45 AM, Christopher Schultz wrote:
> > On 9/7/15 2:17 PM, Sreyan Chakravarty wrote:
> >> I have found the cause of the problem. It seems that there is no
> >> null checking in the DataSourceRealm in Tomcat. What I mean is
> >> that if a particular user does not exist in the database and is
> >> credentials are returned as a null string then no null checking
> >> is specified.
> >
> >> I would like to open this as a bug.
> >
> > https://bz.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%208
> >
> > Before you file a bug:
> >
> > 1. Make sure you test on Tomcat 8.0.26 2. Make sure you post a
> > stack trace from the NPE 3. If you can provide a simple test-case,
> > it would be helpful
> >
> >> The easiest solution is to write a custom Realm that provides
> >> the null checking. The only problem is that now why am I not
> >> being redirected to the error page if I provide a valid user with
> >> a wrong password.
> >
> > If the authenticate() method returns false, then Tomcat should
> > send the user to the form-error-page. It may not issue a redirect,
> > but instead perform a forward. Is that a problem?
> >
> >> Please if anyone can tell me how to write a custom Realm then it
> >> would be really appreciated.
> >
> > If this really is a bug, it should be fixed. I'm skeptical at this
> > point, since nobody has reported this yet. It would be a fairly big
> > bug.
>
> Confirmed by code inspection that Tomcat does not check the return
> value from DataSourceRealm.getPassword. Exactly where the bug lies is
> a matter of opinion:
>
> 1. DataSourceRealm blindly passes the stored credential to the
> CredentialHandler
> 2. MessageDigestCredentialHandler.matches() performs null-checking of
> its arguments
> 3. SecretKeyCredentialHandler.matches() does not perform such
> null-checking
>
> I think it's appropriate for the entire system to waste a little time
> performing the credential-checking algorithm when the username is
> invalid because it mitigates timing-analysis used to perform user
> enumeration. That could be done in each of the individual
> CredentialHandler classes, or it could be done in the Realm itself. I
> would argue it makes sense to do in the Realm, but the handler itself
> could implement such a mechanism, too.
>
> Opinions are welcome.
>
> Please log the bug.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8Do2AAoJEBzwKT+lPKRYNQEP/R1W9tPPrkmRCJMpy+JT63Y1
> GcUblu/0ho1xGd0/NQerpOrePJlAL94RPTkEBCw26DjHZOZ6ehYjgXHBApCIFmze
> LIMlI/x1xe63YgYx19VTCmGv48kLJa97XuoDgHa0Uo2RrAvtG7SaoIiBbFGoI+ID
> J+Ki0ntNvRZshrp4I9GvN9o+HpX19MVmW0Sj58P5a2DpdxwavF3gFRzgpkq8Rxdy
> W+Unbpx4/klI5Gp1W/bp+5j5u8xAS0+KxtsWxzD9ujjHhCCteDqr+2xZVmv4pR3P
> NUlHIdNa6ufOAP6TPM0eQTlFiyx2zRAAJlogCJ1jdYgWe2buaFvmPmFUG8q8JCLQ
> ggdVhtYo4qT1NNr+C0JWvYpmE25IlQN462cIXbcLV43wTReVaNDeeaVWQgwZLiMa
> 3TVS9C5UNGhSVKwPJriHsOECogaswA2fgJSUmDo25zaUAPTul7tT4TsxWbvKuTMI
> QUhAwsm5kqWhv8j9SbphMkmTG2lBBJDczZlemdjHGxofO3dH6q0TtLeR/1ipy9MN
> FML+r3P3D/l08pIPFbU1d2WT32Fvk77f2+x7Zijjx7XJH0gzZT3cGL4z3VtQPfFn
> 6ulWUT6EMsW4g59NEsWyWUPwoQxdyzbXq3QTgygHslEC4vNlOmoewz3uCJLWm0Gd
> MjZcERouuPKa+PiNJBuE
> =l21+
> -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.

[Jose María Zaragoza]

2015-09-09 18:08 GMT+02:00 Jeffrey Janner :
>> -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?

If you write https://hostname/favicon.ico into your browser's url address bar
does it return a JSESSIONID ?
If it does , why do your error html page is creating a HTTP session ?
Is it a error.jsp ?





> Is my solution just providing a favicon.ico file?
> Jeff
>
> -
> 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: Undefined behaviour with Credential Handler

[Sreyan Chakravarty]

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

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

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJV8E9cAAoJEBzwKT+lPKRYvFUQAJOnonwIc7wdMKSbyn6ldsXT
> +2A1gC16QpAnvWgP8RkqDgDn9zPfYBfdRePpI3voDxNJsiKxSuqPhldlPTtyu+28
> 4KWDifi1qxTbhvMasSv1AgwkzMjOBFWitZ8NLbr4AUK/m878Goc0nSUEDIirpLNq
> THfQAL5fvN0IXl6IqDx5dEyGekBQsSg6Q1NqU5ZL6w2GLvhwYBfTE/eFsHzw/mc2
> Z7IIC/gt7wT4FbkzzMF1Qcp6TKvEA1pdLU0KCcE7BiLCiwJxWfQTCI2WWEJIMV2s
> FwkvLDXidqmNIL6Wg4QoaB093lw5UcQY0r2kUtCL4gkuS7IqCyLeFaaJFXoN2iY9
> +OlLlPF1DrsKAhJejDuge1+ixksWDd3VqL6DoMHqldpG5kh1CIPjO3Cwpnw5ypNX
> /v5u4dq318qrcp2UGsr/1mRXx0t7gNUfgqGqS+4wDw40TekGJbGJqhFaVoq82sjz
> gFPOhjTeSDExb0zTiyhaRus4VtqlGUnMj+CIx+4yMDg1ax/Le19yV7if+p4KRaB+
> Ua+D31QY5sz09CIJIog9WOiQ20PGDsWSgQzKevoqZCDgWfx/NChG5rz0ku0DdHsC
> nednB/m8TGrT6ziT33NIbfDGgp31egkI6TjqVcLaK4IX1L073R83sQ9O6m5pqmJ+
> t5YGoYKn1OMac388Rx7N
> =Ha10
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

[Willem van Zyl]

Use dnssec.

Sent by Outlook for Android



On Wed, Sep 9, 2015 at 8:13 AM -0700, "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.

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

[OT] PGP for Java

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

Sorry for the off-topic post, but this community has a variety of
backgrounds and I've found it to be a good place to ask questions like
this.

Does anyone know of a good PGP library for Java? Most of the ones I've
seen are just wrappers around System.exec() and they call the
command-line tools. That seems very fragile to me.

I'm looking for something that is:

1. 100% Java or at least natively-bound to some library like Gnupg
(i.e. no wrappers around System.exec())

2. Does not require the use of Bouncy Castle's crypto

I ask for #2 because BC tends to be insanely slow, since they do
everything in Java and don't have access to the hardware crypto that
the JVM can provide.

So... has anyone done anything like this before?

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

iQIcBAEBCAAGBQJV8JGSAAoJEBzwKT+lPKRY9pYP/0kxE1qqsQFwFcpvp7weI2/a
M9TpSbNAiYPqvYDXvjOgoaETLmzd1nRbpqgbJK7ZDNhTZUOnCDEWpRKlVaWSxJ8J
ritZXLvLV5ZMXnVGEmFEIlJ9FQXclUKc5VLvMEUvPizDnybVCtnNyOY9P8jgnqbz
Ld5APjOhQ9knBc896wFAl1T7mjll7La0k26oCjJYhINcrPUDriLVkSzaNU3nVO9n
+QMLVft5f1XJ1QMC+blDWNEsM0nAQTqKS/VYFDkwwy/PsQH/zpTUDn5BlY8Sd2e7
ul5EoBC26Px7V4E5tU4V3FS7PB12Fxo0+CVrVh7MEE8rfmYZo7PIYLyViJ6BriRe
SPCuD0BK5zeO1VM0HeRgUNvK/T8NFWrM3agAiOwFcn7n3nfmWTzomn+l4AYDX0pv
L/aa8DHtxX/hzmMTLQiBhL8/9bx97Kcr+qiLPy3cbUn2f/7SxME97PFxxF0zI7ei
lM7ecgMRN8IOXHJwQhB6ZHclCzQc6flqg0+GRJldj0DuJEFf+Mwz7cFi5koATpyY
vLfBi2ayNgTEp/zR5A/UR+Xd6E/J1Yd3zt0/r9VHATtoz8x0yNT02KHJ2lYyg0yV
zccJ6P4VJ7pZOleLzo/1dtNI32tr0tE2sGAOVFbZcmuEZ096P9ZmtnP3BBOc+Br+
y3hD//W4ngLv3nKcH0PQ
=vUa5
-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/9/15 3:54 PM, Pottinger, Hardy J. wrote:
> Well... it occurred to me that from time to time we happen to have
> stack traces show up in our log files due to some error or another,
> and, I could just *look* at the log files. Sure enough, here's an
> example of one line of interest (there are many similar ones):
> 
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticat
orBase.java:503)
>
>  Is that enough of a clue?

Ha ha ha, no unfortunately not: pretty much all of the authenticators
extend from AuthenticatorBase, so the only thing it tells us is that
there is at least *some* authenticator.

If nobody else replies, I'll try to trace-through the code to figure
out what kind of authenticator you are getting. I'm guessing
NoLoginAuthenticator is the one, though.

- -chris

> From: Pottinger, Hardy J. Sent: Wednesday, September 09, 2015 9:35
> AM To: Tomcat Users List Subject: RE: seeking help with stabilizing
> the persistence of a JSESSIONID
> 
> Hi, thanks for following up! No, no luck at all. The web
> application I'm working with is based on Apache Cocoon 2.2, so, no
> JSPs in sight. I am actually weighing my options, I have a choice
> to either pursue making the current design work (i.e. try to get
> the session to stick around long enough so I can use it), or else
> change the design and go with a more conventional "pass the return
> URL around as a parameter in the request" approach. I'm leaning
> towards the latter, as it sidesteps this whole issue we're having
> with session fixation protection, *and* it deals with a slightly
> esoteric use case, where a user encounters a password challenge
> when attempting to view a restricted item, backtracks, then later
> chooses to log in for some other reason, and is returned to the
> original restricted item page (because the redirect URL is still in
> the session).
> 
> If I do continue to persue the session route, I'll let you know if
> I'm able to determine what authentication class ends up in the
> stack trace.
> 
> --Hardy  From: Christopher
> Schultz [ch...@christopherschultz.net] Sent: Wednesday, September
> 09, 2015 8:24 AM To: Tomcat Users List Subject: Re: seeking help
> with stabilizing the persistence of a JSESSIONID
> 
> Hardy,
> 
> On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
>>> Are you using AJP or HTTP as your proxy protocol? If AJP, are 
>>> you using tomcatAuthentication="false" on your ?
>>> I'm not exactly sure what happens when you do that... you might
>>> get a NonLoginAuthenticator.
> 
>> in our Vhost file, we have this:
> 
>>  ProxyPass ajp://127.0.0.1:8009/xmlui 
>> retry=1 keepalive=on ProxyPassReverse
>> ajp://127.0.0.1:8009/xmlui ShibUseHeaders On SetEnv
>> proxy-sendchunked 1 
> 
>> in our server.xml file, we have this:  > port="8009" enableLookups="false" redirectPort="8080" 
>> protocol="AJP/1.3" address="127.0.0.1" 
>> tomcatAuthentication="false" maxSwallowSize="-1" 
>> connectionTimeout="1232000" disableUploadTimeout="false" 
>> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
> 
>> So, we're using tomcatAuthentication="false"
> 
>> I will try your suggestion of using NonLoginAuthenticator and
>> see what I get. If it doesn't work, I'll try your suggestion of
>> setting a breakpoint and using a debugger to look at the stack.
> 
> Any luck?
> 
> You don't have to use a debugger to get a stack trace: just create
> a JSP and have it 'throw Exception("getting a stack trace")'.
> 
> -chris
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8JH1AAoJEBzwKT+lPKRYqA8QAIvtWo5jBOYQqcszAqpbfwnP
ZERDPwEISLWfuqbUZbmawB1HI1GI9sMPeUZ7su/NwyOQiCgpgM4kSqR4sxTMAtEC
DMiN9QSNNfs9YErX/UBsisMTfeOwmO1+ME7oU2wQtGD7dirZAM3N5NrADPqTFo9f
eU94YR8TbFq+GViIUvlm2OBxGa/nHZyumcC6BGJ0EroGTG7HUlRkj9OHZJMl+WgC
gCqJ+lPxTuCFI0Q/SdeG+BA2RMBBlTV8UJ26kPGIwBcd+SSCmKgmrglBqteQQZn5
Nq5SXvMpkl+E4JAGeNy9IeGZBOQ3roRxJ47jxWR5p6CS037S+hZIwPEPCsCpEQAU
b68ibgYWLYJnzhmbO90MdppE6vr4dSbKp2x8Gjkt2PV9gCZZBum0SdYGqE7Gbxxp
QBXTXAmeI/0QpBP9JEOuTZSV6DD6KDg3wKEfDzSL2H4LJorBAis1RhOilkMPTrzm
PQWh/MCMcwkj3A+9fItq4uNPK5pfXmOFZ693oB1T9JyQtOhIW3TA7RhpHI2g3fnn
jnXc/s4FNtG7pasfQc2Hxa5VXnp9VMi1cQeRCTcffxm0VEKQ0LkR9mtj/fVPTMEL
xUF8ZLCLlJZ6LdlcbtCCZZpzbQpoyzKBHTYWc1b98OK0opB+W0C41Oyd0+tSpnpj
4qllAkaNMihnhwf4M3v1

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

On the off chance you need the full stack trace here it is:

2015-05-29 15:07:15,216 ERROR 
org.dspace.app.xmlui.cocoon.DSpaceCocoonServletFilter @ Serious Error Occurred 
Processing Request!
org.springframework.web.util.NestedServletException: Handler processing failed; 
nested exception is java.lang.StackOverflowError
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:972)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:852)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:882)
at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:778)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.dspace.app.xmlui.cocoon.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:111)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.dspace.app.xmlui.cocoon.DSpaceCocoonServletFilter.doFilter(DSpaceCocoonServletFilter.java:274)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.dspace.app.xmlui.cocoon.servlet.multipart.DSpaceMultipartFilter.doFilter(DSpaceMultipartFilter.java:119)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.dspace.utils.servlet.DSpaceWebappServletFilter.doFilter(DSpaceWebappServletFilter.java:78)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at 
com.googlecode.psiprobe.Tomcat70AgentValve.invoke(Tomcat70AgentValve.java:38)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:190)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:314)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)


From: Pottinger, Hardy J.
Sent: Wednesday, September 09, 2015 2:54 PM
To: Tomcat Users List
Subject: RE: seeking help with stabilizing the persistence of a JSESSIONID

Well... it occurred to me that from time to time we happen to have stack traces 
show up in our log files due to some error or another, and, I could just *look* 
at the log files. Sure enough, here's an example of one line of interest (there 
are many similar ones):

at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)

Is that enough of a clue?

--Hardy

From: Pottinger, Hardy J.
Sent: Wednesday, September 09, 2015 9:35 AM
To: Tomcat Users List
Subject: RE: seeking help with stabilizing the persistence of a JSESSIONID

Hi, thanks for following up! No, no luck at all. The web application I'm 
working with is based on Apache Cocoon 2.2, so, no JSPs in sight. I am actually 
weighing my options, I have a choice to either pursue making the current 

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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Willem,

On 9/9/15 12:54 PM, Willem van Zyl wrote:
> Use dnssec.

Is it possible for a server to force the use of DNSSEC? Just like
X.509, you need to have a chain of trust between the client and the
server, and if your ISP or OS doesn't support DNSSEC, then you can't
benefit.

- -chris

> On Wed, Sep 9, 2015 at 8:13 AM -0700, "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.
> 
> 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
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJV8JO5AAoJEBzwKT+lPKRYIEwP/i9aMbfCeS+YSXi6CBVpvtXi
Qr93tff50GHXsFFaI4jgqSM75/9O2Z2LmZy2OqmwaDK/scVL2ogQmUiubsNDymUI
xzU3d0zEzcjHZBhkF0XtlwqTqsJp/sx+x08Lk8Ye487EYvr1WTgQj7No22oAUtFK
ucwT697SH9YD4CB2q1PcyOwW88eOr+zjsgymyr7qDmEKXWPRW2oi0/BqAAFBtkZk
w+VTfhf8vOrRZHFDiG9Fl+rPLbepFzQbXsmVD/l4uzNJmCp/ndVISZZ2K9p29Hhu
EkbBNCyZHPv7uUl2ncyOl/FI7G1G3O+S4Q+piZ+clLXA0KB3Epe1wRXuXxUO8yGC
ub3BnMuuV9zqkzzYs0CCX1UU38EtY6AOXZRiSH8kBJz5HMi6RRJFNMl7zeFrajMC
bWJUbUDPiqC9q4slrZ/kAYX5DD5SEoP0GsEA64mFBgV04mGDtny19LX/4ahpN/A4
DJIf9Mqy83yA4e3/NxBwwdNmscyU4DfD8MxA3tt9cNOWmvkBCreyCCPiWlEL/VBL
OUwqO4+EtWE6dkAkobrkrn8KTWeF/obM0FTBZKFqVqYcRlgagDV4MFZwgfQPjRTh
gxpjQJtfnC3br9eEOMe0LBuFeTTAu57RsM8nkYWay75hHuo2f7BATopjjJ+Wd0Ia
GwO8/9QGJnDwGyM9vKR6
=QOAa
-END PGP SIGNATURE-

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

Re: Undefined behaviour with Credential Handler

[Christopher Schultz]

-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: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

Ha, sorry for the useless detail :-)

>>  Is that enough of a clue?
>Ha ha ha, no unfortunately not: pretty much all of the authenticators
>extend from AuthenticatorBase, so the only thing it tells us is that
>there is at least *some* authenticator.
>
>If nobody else replies, I'll try to trace-through the code to figure
>out what kind of authenticator you are getting. I'm guessing
>NoLoginAuthenticator is the one, though.

Thanks for the offer of tracing through the code. If you're really interested, 
here is a starting point:
https://github.com/DSpace/DSpace/tree/master/dspace-api/src/main/java/org/dspace/authenticate


From: Christopher Schultz [ch...@christopherschultz.net]
Sent: Wednesday, September 09, 2015 3:09 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/9/15 3:54 PM, Pottinger, Hardy J. wrote:
> Well... it occurred to me that from time to time we happen to have
> stack traces show up in our log files due to some error or another,
> and, I could just *look* at the log files. Sure enough, here's an
> example of one line of interest (there are many similar ones):
>
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authenticat
orBase.java:503)
>
>  Is that enough of a clue?

Ha ha ha, no unfortunately not: pretty much all of the authenticators
extend from AuthenticatorBase, so the only thing it tells us is that
there is at least *some* authenticator.

If nobody else replies, I'll try to trace-through the code to figure
out what kind of authenticator you are getting. I'm guessing
NoLoginAuthenticator is the one, though.

- -chris

> From: Pottinger, Hardy J. Sent: Wednesday, September 09, 2015 9:35
> AM To: Tomcat Users List Subject: RE: seeking help with stabilizing
> the persistence of a JSESSIONID
>
> Hi, thanks for following up! No, no luck at all. The web
> application I'm working with is based on Apache Cocoon 2.2, so, no
> JSPs in sight. I am actually weighing my options, I have a choice
> to either pursue making the current design work (i.e. try to get
> the session to stick around long enough so I can use it), or else
> change the design and go with a more conventional "pass the return
> URL around as a parameter in the request" approach. I'm leaning
> towards the latter, as it sidesteps this whole issue we're having
> with session fixation protection, *and* it deals with a slightly
> esoteric use case, where a user encounters a password challenge
> when attempting to view a restricted item, backtracks, then later
> chooses to log in for some other reason, and is returned to the
> original restricted item page (because the redirect URL is still in
> the session).
>
> If I do continue to persue the session route, I'll let you know if
> I'm able to determine what authentication class ends up in the
> stack trace.
>
> --Hardy  From: Christopher
> Schultz [ch...@christopherschultz.net] Sent: Wednesday, September
> 09, 2015 8:24 AM To: Tomcat Users List Subject: Re: seeking help
> with stabilizing the persistence of a JSESSIONID
>
> Hardy,
>
> On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
>>> Are you using AJP or HTTP as your proxy protocol? If AJP, are
>>> you using tomcatAuthentication="false" on your ?
>>> I'm not exactly sure what happens when you do that... you might
>>> get a NonLoginAuthenticator.
>
>> in our Vhost file, we have this:
>
>>  ProxyPass ajp://127.0.0.1:8009/xmlui
>> retry=1 keepalive=on ProxyPassReverse
>> ajp://127.0.0.1:8009/xmlui ShibUseHeaders On SetEnv
>> proxy-sendchunked 1 
>
>> in our server.xml file, we have this:  > port="8009" enableLookups="false" redirectPort="8080"
>> protocol="AJP/1.3" address="127.0.0.1"
>> tomcatAuthentication="false" maxSwallowSize="-1"
>> connectionTimeout="1232000" disableUploadTimeout="false"
>> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
>
>> So, we're using tomcatAuthentication="false"
>
>> I will try your suggestion of using NonLoginAuthenticator and
>> see what I get. If it doesn't work, I'll try your suggestion of
>> setting a breakpoint and using a debugger to look at the stack.
>
> Any luck?
>
> You don't have to use a debugger to get a stack trace: just create
> a JSP and have it 'throw Exception("getting a stack trace")'.
>
> -chris
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> -
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: 

RE: seeking help with stabilizing the persistence of a JSESSIONID

[Pottinger, Hardy J.]

Well... it occurred to me that from time to time we happen to have stack traces 
show up in our log files due to some error or another, and, I could just *look* 
at the log files. Sure enough, here's an example of one line of interest (there 
are many similar ones):

at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:503)

Is that enough of a clue?

--Hardy

From: Pottinger, Hardy J.
Sent: Wednesday, September 09, 2015 9:35 AM
To: Tomcat Users List
Subject: RE: seeking help with stabilizing the persistence of a JSESSIONID

Hi, thanks for following up! No, no luck at all. The web application I'm 
working with is based on Apache Cocoon 2.2, so, no JSPs in sight. I am actually 
weighing my options, I have a choice to either pursue making the current design 
work (i.e. try to get the session to stick around long enough so I can use it), 
or else change the design and go with a more conventional "pass the return URL 
around as a parameter in the request" approach. I'm leaning towards the latter, 
as it sidesteps this whole issue we're having with session fixation protection, 
*and* it deals with a slightly esoteric use case, where a user encounters a 
password challenge when attempting to view a restricted item, backtracks, then 
later chooses to log in for some other reason, and is returned to the original 
restricted item page (because the redirect URL is still in the session).

If I do continue to persue the session route, I'll let you know if I'm able to 
determine what authentication class ends up in the stack trace.

--Hardy

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hardy,

On 9/4/15 4:32 PM, Pottinger, Hardy J. wrote:
>> Are you using AJP or HTTP as your proxy protocol? If AJP, are
>> you using tomcatAuthentication="false" on your ? I'm
>> not exactly sure what happens when you do that... you might get
>> a NonLoginAuthenticator.
>
> in our Vhost file, we have this:
>
>  ProxyPass ajp://127.0.0.1:8009/xmlui
> retry=1 keepalive=on ProxyPassReverse  ajp://127.0.0.1:8009/xmlui
> ShibUseHeaders On SetEnv proxy-sendchunked 1 
>
> in our server.xml file, we have this:   port="8009" enableLookups="false" redirectPort="8080"
> protocol="AJP/1.3" address="127.0.0.1"
> tomcatAuthentication="false" maxSwallowSize="-1"
> connectionTimeout="1232000" disableUploadTimeout="false"
> connectionUploadTimeout="1232000" URIEncoding="UTF-8"/>
>
> So, we're using tomcatAuthentication="false"
>
> I will try your suggestion of using NonLoginAuthenticator and see
> what I get. If it doesn't work, I'll try your suggestion of setting
> a breakpoint and using a debugger to look at the stack.

Any luck?

You don't have to use a debugger to get a stack trace: just create a
JSP and have it 'throw Exception("getting a stack trace")'.

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

iQIcBAEBCAAGBQJV8DLwAAoJEBzwKT+lPKRY48YQAIUdyi1UwJTtdmjJBRWLXH7Q
ochdn2fBkBF+nDn1V3mLp7svDrk4SNFdymRUudOgCg4ZF4GHVClYDEVcQFMYKgOB
7NjBNtxTLXKhX7AloY+nYHJaCBEcKsYW3fZXCmNt1/KKCXq2cEcJ264++VUN//sT
khvWjTipOuDQAZYauWfQWb2T4flp5Viitq37zyYpeTD1HeTxepdTFAlPIquFYAlK
bHQQuWpI55YjTTBoDq3+FKabH97DQ1A3mLYcktIvIT4KiHFFlE2F+mb30F60Qdw7
RRDFJhTFGbnr0gIIV1b6VUJyDhh6m4bIXkRCixo41d9JAzzcmkpivaEClO+YTFwF
X8nVRPFkRiFKgKU6Gw0g/fzMNz53LrhW5TPvy7nHe2f+Ahip0M94pS3sD0azh+y0
ZoxG9JyquDQWHPGgwfQqjtide7+u5bo8mEhuUC2tWNl7iSwB7rUFgz9GgyWl7fNi
jRRZ3gCrqaZFdUoJdh9/eUpfzo24DNEPO5mNsD5Ii0REXXGHkalVd1Rk6MyYFc+X
Jt4ZJVG2Jxlcu3Z2G9wUfNBuc/0ejsmHuOKlLeg0++J0QIoKOwZw67k5HD/XoUhT
ieSV9f2LZwA5Wh3vA4o80uC94SWU/4aav6D0qhB5Np6YXy7xtX/q/oGSVu6sr0XY
zg8u3mC90npBIj5b3nPQ
=kWRl
-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


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