On 3/12/2015 10:16 AM, rop wrote:
Hi Chris,
Thanks for your input.
Re your points a+b:
You have put your Realm into conf/context.xml instead of into your web
application's META-INF/context.xml
Actually neither we define the Realm in
$CATALINA_BASE/conf/server.xml
That's also what I
Hi Chris,
Thanks for your input.
Re your points a+b:
You have put your Realm into conf/context.xml instead of into your web
application's META-INF/context.xml
Actually neither we define the Realm in
$CATALINA_BASE/conf/server.xml
That's also what I see in the Tomcat-docs:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the session ID is
generated after a successful
Ah, I got it now.
Thanks, David.
Yes, the a-b-c-d points are OK then.
As a trouble-shoot action, I actually did an install-and-test binary
search
among the intermediate tomcat-versions to pinpoint exactly which version
breaks our app.
Turns out, up to 7.0.47 it still works OK.
(7.0.48 and
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
http://grokbase.com/t/tomcat/users/13bvsbwb8s/multiple-servers-and-digest-authentication
the same problem is described and the recommended solution is to use sticky
load balancing. But, the problem in a tomcat cluster is that the
On 12/03/2015 15:51, rop wrote:
Ah, I got it now.
Thanks, David.
Yes, the a-b-c-d points are OK then.
As a trouble-shoot action, I actually did an install-and-test binary
search
among the intermediate tomcat-versions to pinpoint exactly which version
breaks our app.
Turns out, up to
Sascha, you can configure source address stickyness as well as
destination address stickyness, both will provide the same result
which will work for you.
2015-03-12 18:13 GMT+01:00 Mark Thomas ma...@apache.org:
On 12/03/2015 15:20, Sascha Skorupa wrote:
Hi,
here:
Finally, found the issue.
The crucial change was in the method RealmBase.compareCredentials(),
which is new in 7.0.50 (the comparison was much simpler before that).
Dunno if we do something unusual here,
but we just extend DataSourceRealm, like MyDataSourceRealm,
and implement the message-digest
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Rop,
On 3/12/15 3:33 PM, rop wrote:
Finally, found the issue.
Please bottom-post if you can. Also, please sign your posts.
On Thu, Mar 12, 2015 at 6:18 PM, Mark Thomas ma...@apache.org
wrote:
On 12/03/2015 15:51, rop wrote:
Ah, I got it
Hi Chris,
Yes, we are applying salt before hashing (to prevent googling up many
passwords from the hashes).
Override probably seemed like easiest way at the time, but maybe a better
way now. Will check it out, thanks.
/Rop
On Thu, Mar 12, 2015 at 8:53 PM, Christopher Schultz
10 matches
Mail list logo