date:20111012


On 11/10/11 22:24, Christopher Schultz wrote:

I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)



So, it looks like the Valve should *not* be expiring your SSO when the
static webapp's session expires. Can you confirm that you really are
suffering a timeout? Are there other reasons a session could be
invalidated in any one of your webapps? The static one seems like
the most likely candidate, but one of the others could be doing it.



Can you enable debug logging for
org.apache.catalina.authenticator.SingleSignOn? It looks like there
should be lots of good logging emitted in there for you to check.


It was late at night when I said the SSO Valve was a jsp. Thanks for not 
pointing out my mistake!


I've successfully run a remote debugger session against the SingleSignOn 
Valve while it is handling my timeout scenario.


Interestingly, the logic to handle the timeout of a single webapp is 
exactly as I wanted it to be... only the specific Session is removed 
from the array and the SSOEvent remains cached and valid until the array 
becomes empty. However, when the first of the two Sessions times out, 
the array immediately becomes empty and so the SSOEntry is legitimately 
deregistered!


It seems the second, longer-lived, webapp's Session is no longer 
associated with the existing SSOEntry when the first webapp times out. I 
noticed the second Session being validated, but didn't follow that 
particular bit of logic. I will run the scenario again to see what 
happens when the second webapp is first called.


Brian

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

Re: SingleSignonValve and webapp session timeout

2011-10-12 Thread Konstantin Kolinko

2011/10/12 Brian Burch br...@pingtoo.com:

 I've successfully run a remote debugger session against the SingleSignOn
 Valve while it is handling my timeout scenario.

 Interestingly, the logic to handle the timeout of a single webapp is exactly
 as I wanted it to be... only the specific Session is removed from the array
 and the SSOEvent remains cached and valid until the array becomes empty.
 However, when the first of the two Sessions times out, the array immediately
 becomes empty and so the SSOEntry is legitimately deregistered!

 It seems the second, longer-lived, webapp's Session is no longer associated
 with the existing SSOEntry when the first webapp times out. I noticed the
 second Session being validated, but didn't follow that particular bit of
 logic. I will run the scenario again to see what happens when the second
 webapp is first called.


Something becomes clearer.

Remembering the session as associated with ssoid is performed by
SingleSignOn.associate(..) method. This method is called by
AuthenticatorBase class.

Those webapps with long living sessions - are they protected by
security constraints in their web.xml?

(If they are not, then authentication does not happen and their
sessions are not associated with SSO)/

Best regards,
Konstantin Kolinko

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

Re: SingleSignonValve and webapp session timeout


On 12/10/11 12:51, Konstantin Kolinko wrote:

Something becomes clearer.

Remembering the session as associated with ssoid is performed by
SingleSignOn.associate(..) method. This method is called by
AuthenticatorBase class.

Those webapps with long living sessions - are they protected by
security constraints in their web.xml?

(If they are not, then authentication does not happen and their
sessions are not associated with SSO)/


Yes, they are constrained and once the SSO has been invalidated, they 
are forced through my standard login/menu mechanism by catching the 403 
error status.


My tomcat 6.0.28 compiled class for AuthenticatorBase does not match the 
6.0.33 source code I am debugging with. The SSO Valve is pretty much the 
same.


The 6.0.33 AuthenticatorBase.register() method has a lot of stuff about 
SSO and it mentions a bug fix number 10040 in some comments that sound 
quite relevant to my symptoms. I haven't been able to reconcile the 
source code and can't find the bug report yet.


Brian

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

RE: ssl handshake problem

2011-10-12 Thread Edward Quick

Found out the reason for the ssl handshake error. The certificate chain was in 
the wrong order (being server certificate, Root CA, Intermediate, instead of 
server certificate, Intermediate, Root CA).

-Original Message-
From: Edward Quick [mailto:edward.qu...@iggroup.com] 
Sent: 12 October 2011 08:12
To: Tomcat Users List
Subject: RE: ssl handshake problem

Thanks for your reply Chris. No I'm not confident a restart would fix it. 
Having said that I haven't seen the ssl handshake problem since yesterday 
(which might be because the app hasn't tried the address yet) so waiting to see 
if it happens again. Unfortunately I don't have a way to invoke it.

All my question was really is whether tomcat or java somehow caches an https 
site's old ssl certificate for a while and checks its truststore against this 
instead of the new one?

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: 11 October 2011 16:30
To: Tomcat Users List
Subject: Re: ssl handshake problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Edward,

On 10/11/2011 9:21 AM, Edward Quick wrote:
 I have an ssl handshake issue with an application running on
 tomcat that talks to an ssl site. This site renewed their ssl
 certificate recently, however it was signed with the G5 and G3
 intermediate verisign CA certificates which are imported into the
 java truststore that my tomcat uses.

 If I run a short java program from the command line to connect to
 the site using tomcat's truststore it works fine. I'm just
 wondering if tomcat needs a restart to pick the new certificate up
 from this site? Or is there an mbean operation I can invoke to
 clear this out? Obviously I'm speculating, but I'm a bit stuck on
 this and as it's running a live service, it's not easy to restart.

So, if the service is restarted, you're confident that the handshake
will work? If that's the case, I believe a Tomcat restart is your only
option at this point.

Another option would be to manage your own trust store for your
outgoing communications instead of relying on Tomcat's trust store. Of
course, that requires you to modify your webapp which might not be
terribly convenient.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6UYPUACgkQ9CaO5/Lv0PAGsgCfc9ORPVz7v9GlwhQZFRhVJZRr
jhoAn1r/Sl+KR57wfi8UwRTjkOMD5TTQ
=9b/8
-END PGP SIGNATURE-

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

The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Group Holdings plc is a company registered in England and Wales under 
number 01190902. VAT registration number 761 2978 07. Registered Office: Cannon 
Bridge House, 25 Dowgate Hill, London EC4R 2YA. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.

redirection error due to context path after JAAS authentication with mod_proxy

2011-10-12 Thread Woonsan Ko

Hi,

I have a reverse proxy configuration like this:

VirtualHost *:80 
  ServerName localhost 
  ProxyPreserveHost On 
  ProxyPass / http://localhost:8080/app1/ 
  ProxyPassReverse / http://localhost:8080/app1/ 
  ProxyPassReverseCookiePath /app1 / 
/VirtualHost

And, I have a form-based login configuration for JAAS authentication.
When I try log on, the redirect location (the secured resource path) after 
/j_security_check seems to be prepended by the context path, '/app1'. (e.g. 
Location: http://localhost/app1/login/resource, instead of 
http://localhost/login/resource)
I guess there will be other solutions with more sophisticated configuration for 
mod_proxy by adding more external server addresses. 
However, I'd like to avoid that if possible because the external addresses can 
be changed/added at any time.

Is there any way to customize the redirection after authentication (e.g. by 
using absolute url generation with a custom component) ?

Regards,

Woonsan

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

Pound Signs in Context/Paths

2011-10-12 Thread Richard W. Adams

My Tomcat Version: 6.0.18.0 (running under Jboss)

I'm trying to understand the script we use to deploy to our Tomcat server. 
=

The scripts uses pound signs (#) instead of slashes in the path to the WAR 
=

file being deployed. Let me first be clear:  The script works. What I=20
DON'T understand is why, or the purpose of the pound signs.  I tried=20
searching the Web for documentation on the use of the pound signs, but=20
came up dry.  I'm concerned that we might be using an undocumented feature 
=

that could break in future versions of Tomcat.

Can anyone point me to official documentation about pound signs (#) in=20
Tomcat paths/contexts?

**

This email and any attachments may contain information that is confidential 
and/or privileged for the sole use of the intended recipient.  Any use, review, 
disclosure, copying, distribution or reliance by others, and any forwarding of 
this email or its contents, without the express permission of the sender is 
strictly prohibited by law.  If you are not the intended recipient, please 
contact the sender immediately, delete the e-mail and destroy all copies.
**

manager trying to use JAASRealm vice tomcat-users.xml

2011-10-12 Thread Lund, Holly (CONTR)

Tomcat 6.0.32 and java 1.6 on solaris 10
Uncommented the connector 8080 and changed port to 37799 (due to firewall 
constraints)


Connector port=37799 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /


added user for manager-gui and role for manager-gui in tomcat-users.xml

  role rolename=manager-gui/
  user username=frankh password=x roles=manager,manager-gui/


When I try to log into manager get following error in catalina.out

Oct 12, 2011 8:55:07 AM org.apache.catalina.realm.JAASRealm authenticate
SEVERE: Unexpected error
java.lang.SecurityException: Unable to locate a login configuration
at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:93)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at javax.security.auth.login.Configuration$3.run(Configuration.java:247)
at java.security.AccessController.doPrivileged(Native Method)
at 
javax.security.auth.login.Configuration.getConfiguration(Configuration.java:242)
at javax.security.auth.login.LoginContext$1.run(LoginContext.java:237)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.init(LoginContext.java:234)
at javax.security.auth.login.LoginContext.init(LoginContext.java:403)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:393)
at org.apache.catalina.realm.JAASRealm.authenticate(JAASRealm.java:334)
at 
org.apache.catalina.authenticator.BasicAuthenticator.authenticate(BasicAuthenticator.java:181)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:528)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Unable to locate a login configuration
at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:250)
at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:91)
... 25 more


What am I doing wrong

I have not set up any JAASRealms







Holly Lund
EES, LLC, 
Contractor to the
United States Department of Energy
1000 Independence Avenue, SW
Washington, DC 20585
Phone:202-586-4431
Email:holly.l...@hq.doe.gov



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

Re: ssl handshake problem

Edward Quick wrote:

Thanks for your reply Chris. No I'm not confident a restart would fix it.
Having said that I haven't seen the ssl handshake problem since yesterday
(which might be because the app hasn't tried the address yet) so waiting to see
if it happens again. Unfortunately I don't have a way to invoke it.

All my question was really is whether tomcat or java somehow caches an https
site's old ssl certificate for a while and checks its truststore against this
instead of the new one?

Maybe something to add : as I understand your original description, this is about a webapp
(running inside of Tomcat) which establishes its own SSL connection to some other server.
In such a case, as far as I know Tomcat is not involved at all. It doesn't even know that
the webapp is doing that, and has no reason to be caching anything.

This being said, since both Tomcat and the webapp run inside the same JVM, there may be
things cached /by the JVM/.
My knowledge of these things is insufficient to know if such things cached by the JVM
could be shared between Tomcat and the webapp.
Intuitively however, I would tend to think that whatever in-memory structure/object is
used by Tomcat for its own SSL Connector(s), is probably distinct from the in-memory
structure/object used by this webapp to store information related to its own independent
connections.

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

Re: Pound Signs in Context/Paths

2011-10-12 Thread Pid

On 12/10/2011 15:55, Richard W. Adams wrote:
 My Tomcat Version: 6.0.18.0 (running under Jboss)

That's old.

 I'm trying to understand the script we use to deploy to our Tomcat server. 
 =
 
 The scripts uses pound signs (#) instead of slashes in the path to the WAR 
 =
 
 file being deployed. Let me first be clear:  The script works. What I=20
 DON'T understand is why, or the purpose of the pound signs.  I tried=20
 searching the Web for documentation on the use of the pound signs, but=20
 came up dry.  I'm concerned that we might be using an undocumented feature 
 =
 
 that could break in future versions of Tomcat.
 
 Can anyone point me to official documentation about pound signs (#) in=20
 Tomcat paths/contexts?

 tomcat/webapps/myapp#is#here.war

is published as

 http://hostname/myapp/is/here
^^

where the highlighted part is the context path.

This is called mult-level paths:

  http://tomcat.apache.org/tomcat-6.0-doc/config/context.html



p



signature.asc
Description: OpenPGP digital signature

Re: redirection error due to context path after JAAS authentication with mod_proxy


Woonsan Ko wrote:

Hi,

I have a reverse proxy configuration like this:

VirtualHost *:80 
  ServerName localhost 
  ProxyPreserveHost On 
  ProxyPass / http://localhost:8080/app1/ 
  ProxyPassReverse / http://localhost:8080/app1/ 
  ProxyPassReverseCookiePath /app1 / 
/VirtualHost


If it is really like above, then why are you using an Apache httpd front-end at 
all?
Would it not be easier (+ simpler, + more efficient) to just get Tomcat to listen on port 
80 and whatever IP address Apache httpd is listening to right now ?


(To get exactly the same behaviour as above, you would also have to make app1 be the 
Tomcat ROOT application.)


Note: I also use a lot of setups with Apache httpd as front-end, and Tomcat as a back-end, 
and sometimes this is very practical.  At least, when the Apache httpd front-end is 
actually doing something other than forwarding the requests to Tomcat.

But here, it does not seem to be doing anything at all.


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

Re: Pound Signs in Context/Paths

Hi.

[OT] How do you manage to send the text of your messages in quoted-printable
form ?

Richard W. Adams wrote:

My Tomcat Version: 6.0.18.0 (running under Jboss)

I'm trying to understand the script we use to deploy to our Tomcat server.
=

The scripts uses pound signs (#) instead of slashes in the path to the WAR
=

file being deployed. Let me first be clear: The script works. What I=20
DON'T understand is why, or the purpose of the pound signs. I tried=20
searching the Web for documentation on the use of the pound signs, but=20
came up dry. I'm concerned that we might be using an undocumented feature
=

that could break in future versions of Tomcat.

Can anyone point me to official documentation about pound signs (#) in=20
Tomcat paths/contexts?

You are right, this is not particularloy easy to find.
Several mentions to the use of # in paths are made in this section of the on-line
documentation.

http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic%20Application%20Deployment

I do not really understand it very well myself, but as a starter to dig further
:
If you use foo#bar.war a .war file name, and you drop this .war file in Tomcat's webapps
directory, it will be deployed at the path (tomcat_dir)/webapps/foo/bar/.

So it's a trick when you actually want to deploy an application that way, because of
course you cannot name your war file foo/bar.war.
And you can also not drop a bar.war file in the directory (tomcat_dir)/webapps/foo/,
because it would never get deployed.

I know that this is a very limited way to describe this feature, but maybe someone else
here will point you to further info of interest.

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

RE: manager trying to use JAASRealm vice tomcat-users.xml

 From: Lund, Holly (CONTR) [mailto:holly.l...@hq.doe.gov] 
 Subject: manager trying to use JAASRealm vice tomcat-users.xml

 Tomcat 6.0.32 and java 1.6 on solaris 10

Good to know; thanks.

 Uncommented the connector 8080

That's very odd, since that Connector is not commented out in the standard 
server.xml.

 added user for manager-gui and role for manager-gui in tomcat-users.xml

Did you remove the comment markers?  Send us the file, with passwords obscured.

 When I try to log into manager get following error in catalina.out
 Oct 12, 2011 8:55:07 AM org.apache.catalina.realm.JAASRealm authenticate
 SEVERE: Unexpected error
 java.lang.SecurityException: Unable to locate a login configuration

 What am I doing wrong

Not sending us your entire server.xml (with sensitive information obscured); it 
sounds like your server.xml is a bit different from the standard one.  I would 
guess the UserDatabaseRealm has been commented out or removed.

 - Chuck

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

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

RE: manager trying to use JAASRealm vice tomcat-users.xml

2011-10-12 Thread Lund, Holly (CONTR)

Umcommented the UserDatabaseRealm section

Server.xml file

?xml version='1.0' encoding='utf-8'?
!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the License); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an AS IS BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
--
!-- Note:  A Server is not itself a Container, so you may not
 define subcomponents such as Valves at this level.
 Documentation at /docs/config/server.html
 --
Server port=8005 shutdown=SHUTDOWN

  !--APR library loader. Documentation at /docs/apr.html --

  Listener className=org.apache.catalina.core.AprLifecycleListener 
SSLEngine=on /

  !--Initialize Jasper prior to webapps are loaded. Documentation at 
/docs/jasper-howto.html --

  Listener className=org.apache.catalina.core.JasperListener /

  !-- Prevent memory leaks due to use of particular java/javax APIs--

  Listener 
className=org.apache.catalina.core.JreMemoryLeakPreventionListener /

  !-- JMX Support for the Tomcat server. Documentation at 
/docs/non-existent.html --

  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener /
  Listener 
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener /

  !-- Global JNDI resources
   Documentation at /docs/jndi-resources-howto.html
  --

  GlobalNamingResources
!-- Editable user database that can also be used by
 UserDatabaseRealm to authenticate users
--
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
  description=User database that can be updated and saved
  factory=org.apache.catalina.users.MemoryUserDatabaseFactory
  pathname=conf/tomcat-users.xml /
  /GlobalNamingResources
  !-- A Service is a collection of one or more Connectors that share
   a single Container Note:  A Service is not itself a Container,
   so you may not define subcomponents such as Valves at this level.
   Documentation at /docs/config/service.html
   --
  Service name=Catalina

!--The connectors can use a shared executor, you can define one or more 
named thread pools--

!--
Executor name=tomcatThreadPool namePrefix=catalina-exec-
maxThreads=150 minSpareThreads=4/
--


!-- A Connector represents an endpoint by which requests are received
 and responses are returned. Documentation at :
 Java HTTP Connector: /docs/config/http.html (blocking  non-blocking)
 Java AJP  Connector: /docs/config/ajp.html
 APR (HTTP/AJP) Connector: /docs/apr.html
 Define a non-SSL HTTP/1.1 Connector on port 8080
--
Connector port=37799 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /
!-- A Connector using the shared thread pool--
!--
Connector executor=tomcatThreadPool
   port=37799 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /
--
!-- Define a SSL HTTP/1.1 Connector on port 8443
 This connector uses the JSSE configuration, when using APR, the
 connector should be using the OpenSSL style configuration
 described in the APR documentation --

!--
Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true
   maxThreads=150 scheme=https secure=true
   clientAuth=false sslProtocol=TLS /
--

!-- Define an AJP 1.3 Connector on port 8009 --

!-- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 /  --

Connector port=8109 protocol=AJP/1.3 redirectPort=8443 
connectionTimeout=30 disableUploadTimeout=false maxT
hreads=500 /

!-- connector for OEM --
Connector port=37790 maxHttpHeaderSize=8192
   maxThreads=150 minSpareThreads=25 maxSpareThreads=75
   enableLookups=false redirectPort=8443 acceptCount=100
   connectionTimeout=2 disableUploadTimeout=true /


!-- An Engine represents the entry point (within Catalina) that processes
 every request.  The Engine implementation for Tomcat stand alone
 analyzes the HTTP headers included with the request, and passes them
 on to the appropriate Host (virtual host).
 Documentation at /docs/config/engine.html --

!-- You should set jvmRoute to support load-balancing via AJP ie :
Engine name=Catalina defaultHost=localhost jvmRoute=jvm1
--

Re: redirection error due to context path after JAAS authentication with mod_proxy

2011-10-12 Thread Woonsan Ko

- Original Message -
 From: André Warnier a...@ice-sa.com
 To: Tomcat Users List users@tomcat.apache.org
 Cc: 
 Sent: Wednesday, October 12, 2011 11:52 AM
 Subject: Re: redirection error due to context path after JAAS authentication 
 with mod_proxy

 Woonsan Ko wrote:
  Hi,

  I have a reverse proxy configuration like this:

  VirtualHost *:80   ServerName localhost   ProxyPreserveHost On  
 ProxyPass / http://localhost:8080/app1/   ProxyPassReverse / 
 http://localhost:8080/app1/   ProxyPassReverseCookiePath /app1 / 
 /VirtualHost

 If it is really like above, then why are you using an Apache httpd front-end 
 at 
 all?
 Would it not be easier (+ simpler, + more efficient) to just get Tomcat to 
 listen on port 80 and whatever IP address Apache httpd is listening to right 
 now 
 ?

One simple strong reason is that I don't want to run tomcat by root.

Thanks,

Woonsan

 (To get exactly the same behaviour as above, you would also have to make 
 app1 be the Tomcat ROOT application.)

 Note: I also use a lot of setups with Apache httpd as front-end, and Tomcat 
 as a 
 back-end, and sometimes this is very practical.  At least, when the Apache 
 httpd 
 front-end is actually doing something other than forwarding the 
 requests to Tomcat.
 But here, it does not seem to be doing anything at all.

 -
 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: redirection error due to context path after JAAS authentication with mod_proxy

2011-10-12 Thread Pid

On 12/10/2011 17:51, Woonsan Ko wrote:

 - Original Message -
 From: André Warnier a...@ice-sa.com
 To: Tomcat Users List users@tomcat.apache.org
 Cc: 
 Sent: Wednesday, October 12, 2011 11:52 AM
 Subject: Re: redirection error due to context path after JAAS authentication 
 with mod_proxy

 Woonsan Ko wrote:
  Hi,

  I have a reverse proxy configuration like this:

  VirtualHost *:80   ServerName localhost   ProxyPreserveHost On  
 ProxyPass / http://localhost:8080/app1/   ProxyPassReverse / 
 http://localhost:8080/app1/   ProxyPassReverseCookiePath /app1 / 
 /VirtualHost

 If it is really like above, then why are you using an Apache httpd front-end 
 at 
 all?
 Would it not be easier (+ simpler, + more efficient) to just get Tomcat to 
 listen on port 80 and whatever IP address Apache httpd is listening to right 
 now 
 ?

 One simple strong reason is that I don't want to run tomcat by root.

JSVC, iptables, Tanuki - bunch of different way to handle that.

p

 (To get exactly the same behaviour as above, you would also have to make 
 app1 be the Tomcat ROOT application.)

 Note: I also use a lot of setups with Apache httpd as front-end, and Tomcat 
 as a 
 back-end, and sometimes this is very practical.  At least, when the Apache 
 httpd 
 front-end is actually doing something other than forwarding the 
 requests to Tomcat.
 But here, it does not seem to be doing anything at all.

 -
 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

signature.asc
Description: OpenPGP digital signature

Re: redirection error due to context path after JAAS authentication with mod_proxy


On 12/10/11 17:51, Woonsan Ko wrote:

One simple strong reason is that I don't want to run tomcat by root.


The debian/ubuntu deb package installs tomcat6 so that it uses authbind 
to listen on ports  1024, and it runs under its own non-root uid/gid. I 
was very impressed when I converted from tomcat5 as a vanilla install to 
tomcat6 as a deb.


Even if you are not on debian, perhaps looking at the installation 
script and file structure will help you set up something similar.


Regards,

Brian

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

Re: SingleSignonValve and webapp session timeout

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian,

On 10/12/2011 8:53 AM, Brian Burch wrote:
 My tomcat 6.0.28 compiled class for AuthenticatorBase does not
 match the 6.0.33 source code I am debugging with. The SSO Valve is
 pretty much the same.

So get the source for 6.0.28:

http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.28/src/
or
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_28/

 The 6.0.33 AuthenticatorBase.register() method has a lot of stuff 
 about SSO and it mentions a bug fix number 10040 in some comments 
 that sound quite relevant to my symptoms.

That bug was fixed in 2003, in TC4 and TC5. The first stable release of
TC6, 6.0.10, was released on 2007-02-28, so that shouldn't be your
problem.

 I haven't been able to reconcile the source code and can't find
 the bug report yet.

https://issues.apache.org/bugzilla/show_bug.cgi?id=10040

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6V1vAACgkQ9CaO5/Lv0PAzhwCgvn4g3oKA/02N/eFInPwE7Ifl
1vQAn0wN37DhZhQxsmsL1ZDH6HuI4tBB
=8ith
-END PGP SIGNATURE-

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

Re: manager trying to use JAASRealm vice tomcat-users.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Holly,

On 10/12/2011 12:50 PM, Lund, Holly (CONTR) wrote:
 Umcommented the UserDatabaseRealm section

Really?

 !-- This Realm uses the UserDatabase configured in the global
 JNDI resources under the key UserDatabase.  Any edits that are
 performed against this UserDatabase are immediately available for
 use by the Realm.  -- !-- Realm
 className=org.apache.catalina.realm.UserDatabaseRealm 
 resourceName=UserDatabase/ --

Looks like it's still commented-out to me.

 Oct 12, 2011 12:45:35 PM org.apache.catalina.realm.JAASRealm
 setContainer INFO: Set JAAS app name Catalina Oct 12, 2011 12:45:35
 PM org.apache.tomcat.util.digester.Digester fatalError SEVERE:
 Parse Fatal Error at line 1 column 2: The markup in the document
 preceding the root element must be well-formed. 
 org.xml.sax.SAXParseException: The markup in the document preceding
 the root element must be well-formed.

This is a different problem:


Tomcat-users.xml

 -xml version='1.0' encoding='utf-8'?
!--
  Licensed to the Apache Software Found

You have  -xml which isn't a valid processing instruction. You want
?xml instead.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6V21QACgkQ9CaO5/Lv0PADggCfVP5pA87PV1H/6I3EZbb7AC2/
J3oAoLLPZRBdNLkj9IHnrZYHGH+QzHq1
=QlOG
-END PGP SIGNATURE-

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

Re: SingleSignonValve and webapp session timeout


On 12/10/11 12:35, Brian Burch wrote:

I've successfully run a remote debugger session against the SingleSignOn
Valve while it is handling my timeout scenario.

Interestingly, the logic to handle the timeout of a single webapp is
exactly as I wanted it to be... only the specific Session is removed
from the array and the SSOEvent remains cached and valid until the array
becomes empty. However, when the first of the two Sessions times out,
the array immediately becomes empty and so the SSOEntry is legitimately
deregistered!

It seems the second, longer-lived, webapp's Session is no longer
associated with the existing SSOEntry when the first webapp times out. I
noticed the second Session being validated, but didn't follow that
particular bit of logic. I will run the scenario again to see what
happens when the second webapp is first called.


OK, it now all makes some kind of sense. I've discovered that the 
Session associated with the second webapp is never being associated with 
the SSO instance created by the first webapp. However, the weird thing 
is that the protected resources of the second webapp are made available 
to the signed-on user through the correct SSO identity.


The reason is that the web.xml of the second webapp does NOT have a 
login-config section at all, so an auth-method is not explicitly 
assigned to it. I had not realised this before, but by default the 
NoLoginAuthenticator class is used. The authenticate() method of this 
no-op class DOES NOT add the Session instance of the second webapp to 
the SSO array it has been properly associated with.


In other words, all of my other webapps never get associated with the 
existing SSO Session array, so they all get timed-out simultaneously 
with the first one... effectively, their individual session timeouts are 
ignored.


These non-first webapps do not have a login-config because users will 
NEVER be able to login to their containers - unauthenticated users will 
be redirected to the common static login and menu container.


I'll do a bit more research on the logic within the various 
Authenticator classes to see whether the NoLoginAuthenticator is 
behaving correctly, because I'm not convinced it is yet.


Worse case: code a login-config section for each of my webapps, even 
though it will never be used to execute code and will only trigger the 
association of the new Session instance and therefore have it live 
under its own timeout and preserve the SSO instance accordingly.


Best case: either change NoLoginAuthenticator or write my own variant 
that actually makes the SSO-to-Session association that I need.


(words of encouragement or enlightenment will be appreciated!)

Brian

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

RE: manager trying to use JAASRealm vice tomcat-users.xml

2011-10-12 Thread Lund, Holly (CONTR)

Thanks

Change to ?xml in tomcat-users.xml and uncommmenting additional Realm config  
fixed issue

Holly Lund
EES, LLC, 
Contractor to the
United States Department of Energy
1000 Independence Avenue, SW
Washington, DC 20585
Phone:202-586-4431
Email:holly.l...@hq.doe.gov


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, October 12, 2011 2:24 PM
To: Tomcat Users List
Subject: Re: manager trying to use JAASRealm vice tomcat-users.xml

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Holly,

On 10/12/2011 12:50 PM, Lund, Holly (CONTR) wrote:
 Umcommented the UserDatabaseRealm section

Really?

 !-- This Realm uses the UserDatabase configured in the global JNDI 
 resources under the key UserDatabase.  Any edits that are performed 
 against this UserDatabase are immediately available for use by the 
 Realm.  -- !-- Realm 
 className=org.apache.catalina.realm.UserDatabaseRealm
 resourceName=UserDatabase/ --

Looks like it's still commented-out to me.

 Oct 12, 2011 12:45:35 PM org.apache.catalina.realm.JAASRealm
 setContainer INFO: Set JAAS app name Catalina Oct 12, 2011 12:45:35 PM 
 org.apache.tomcat.util.digester.Digester fatalError SEVERE:
 Parse Fatal Error at line 1 column 2: The markup in the document 
 preceding the root element must be well-formed.
 org.xml.sax.SAXParseException: The markup in the document preceding 
 the root element must be well-formed.

This is a different problem:


Tomcat-users.xml

 -xml version='1.0' encoding='utf-8'?
!--
  Licensed to the Apache Software Found

You have  -xml which isn't a valid processing instruction. You want ?xml 
instead.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6V21QACgkQ9CaO5/Lv0PADggCfVP5pA87PV1H/6I3EZbb7AC2/
J3oAoLLPZRBdNLkj9IHnrZYHGH+QzHq1
=QlOG
-END PGP SIGNATURE-

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

Tomcat connector for IIS, are user groups passed along?

2011-10-12 Thread Marcel Stör

Scenario: use Integrated Windows Security (Kerberos/NTLM) for the site 
in IIS that delegates to Tomcat.


Question: would the ISAPI connector be able to pass the Active Directory 
groups (i.e. user's membership info) along to Tomcat in the request?
Question 2: if yes, could I call request.isUserInRole(roleName) in the 
Tomcat app?


Cheers,
Marcel

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O ascii ribbon campaign - stop html mail - www.asciiribbon.org

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

Re: Tomcat connector for IIS, are user groups passed along?

Marcel Stör wrote:
Scenario: use Integrated Windows Security (Kerberos/NTLM) for the site
in IIS that delegates to Tomcat.

Question: would the ISAPI connector be able to pass the Active Directory
groups (i.e. user's membership info) along to Tomcat in the request?

I am not the ultimate expert on this, but awaiting the ultimate expert's confirmation, I
would say :

- it does not do it right now
- it would probably require serious coding changes to do it (notably because in the AJP
protocol, there is no attribute or packet type foreseen to pass such information per se)
- and there are some conceptual issues linked to this, essentially because the very notion
of AD/NTLM user groups is something valid only in an MS-centric context (and Tomcat
has to work in other contexts).

(*)

Question 2: if yes, could I call request.isUserInRole(roleName) in the
Tomcat app?

If you mean to say that you would use the name of an NTLM group as roleName
above,
that'a a different matter, and also with some conceptual difficulties. The notions of
roles in Tomcat, and the notion of user groups are somewhat different.

This being said, there is one (commercial but affordable) product which allows you to do
something of the kind. Have a look at Jespa (www.ioplex.com). Download the product
(free), and read the User's Guide that comes with it, particularly what it has to say
about user groups and roles.

This product works purely at the Tomcat level, as an authenticating servlet
filter.
So it does not use the authentication already made by IIS, it does it all at the Tomcat
level. This may of may not suit your needs, but if your ultimate purpose is to have a
Windows Domain kind of authentication and SSO, and allow/deny access to applications based
on user Domain group membership, then it can do that.

For another option, in Tomcat 7.x there is also a new SPNEGO authentication mechanism
available, described here :
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve

I really do not know much about it, as I use the Jespa mentioned above.
Maybe someone else can opine if this Valve provides access to the user's NTLM
groups ?

(*) Also, but probably a very long shot : some recent discussion on this list, prompted by
someone having difficulties with large headers being passed to Tomcat via AJP, seemed to
indicate that the NTLM Authorization headers which are sent by the (authenticated) browser
to Tomcat (via IIS), include the user's group membership in some form. This is probably
encrypted, but it may be possible to decrypt this at the Tomcat level.

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

Application not logging out properly

Hello

 

I'm using Apache Tomcat 6.0.26 for an application where the majority of the
content is hidden behind a page requiring authenticated login. This appears
to work fine but upon logout, I find I am able to browse back through some
of the pages visited in the session. 

 

As far as I'm aware, and in other applications I've seen and worked on, this
shouldn't happen.

 

I'm using a listener to detect sessions created and destroyed and this seems
to be fine because I'm recording events in the database when these happen. 

 

My log out instruction is present on most pages as follows:  

 

a href = /myApp/jsp/index/index.jsp?logoff=true title = Log out.

 

And in the index.jsp cited above, I have code:

 

%

   // Log out.

   if (request.getParameter(logoff) != null) { 

session.invalidate();   

response.sendRedirect(/myApp/);   

return;

   }

%

 

Which returns a user to the login page.

 

The problem is only occasional and I can see no pattern to it,  but it
happens under two different installations of version 6.0.26 on different
machines. So either this version is the cause which I don't believe because
other applications seems unaffected, or my application has an issue which I
can't find. 

 

Any ideas?

 

Thanks

 

Martin O'Shea.

RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com] 
 Subject: Application not logging out properly

 upon logout, I find I am able to browse back through some
 of the pages visited in the session. 

Are you sure it's not the browser simply displaying previously cached pages?  
If so, then have your webapp (or a filter) set the appropriate no-caching 
headers.

 - Chuck

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

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

Re: Application not logging out properly


Martin O'Shea wrote:

Hello

 


I'm using Apache Tomcat 6.0.26 for an application where the majority of the
content is hidden behind a page requiring authenticated login. This appears
to work fine but upon logout, I find I am able to browse back through some
of the pages visited in the session. 



What authentication type (scheme) are you using ?
HTTP Basic, form-based, .. ?


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

RE: Application not logging out properly

I'm using form based authentication as follows:

h2 style = text-align: lefta name = loginLogin/a/h2
form method = POST action='%=
response.encodeURL(j_security_check) %'
table border=0
tr
td align = rightName:/td
td align = leftinput type=text
name=j_username/td
/tr
tr
td align = rightPassword:/td
td align = leftinput type=password
name=j_password/td
/tr
tr
td align = rightinput class = button
type=submit value=Log in/td
td align = leftinput class = button
type=reset value = Clear/td
/tr
/table
/form

And the code in web.xml is as follows:

login-config
auth-methodFORM/auth-method
realm-nameForm-Based Authentication Area/realm-name
form-login-config
 
form-login-page/jsp/security/protected/login.jsp/form-login-page
 
form-error-page/jsp/security/protected/error.jsp/form-error-page
/form-login-config
/login-config
security-role
description/
role-nameADMIN/role-name
/security-role

I also have MD5 digest specified in context.xml.

-Original Message-
From: André Warnier [mailto:a...@ice-sa.com] 
Sent: 12 Oct 2011 22 19
To: Tomcat Users List
Subject: Re: Application not logging out properly

Martin O'Shea wrote:
 Hello
 
  
 
 I'm using Apache Tomcat 6.0.26 for an application where the majority 
 of the content is hidden behind a page requiring authenticated login. 
 This appears to work fine but upon logout, I find I am able to browse 
 back through some of the pages visited in the session.
 

What authentication type (scheme) are you using ?
HTTP Basic, form-based, .. ?


-
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: Application not logging out properly

I would rather avoid forcing the browser to reload each page via the
appropriate headers. 

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: 12 Oct 2011 22 18
To: Tomcat Users List
Subject: RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com]
 Subject: Application not logging out properly

 upon logout, I find I am able to browse back through some of the pages 
 visited in the session.

Are you sure it's not the browser simply displaying previously cached pages?
If so, then have your webapp (or a filter) set the appropriate no-caching
headers.

 - Chuck

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

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

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

RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com] 
 Subject: RE: Application not logging out properly

 I would rather avoid forcing the browser to reload each 
 page via the appropriate headers. 

Then they're going to be available in the browser cache until the browser 
chooses to discard them.  You can't have it both ways.

 - Chuck

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

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

RE: Application not logging out properly

This is true of the current application, but also true of the other Tomcat
applications I have. 

But the others don't seem to have this problem. I know the sessions are
invalidating because if I try to do something on one of the pages visited in
the session, the login page appears automatically.

Using a filter to prevent caching does seem a sledgehammer approach. But I
have set one up to do just that but I would prefer another solution.

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: 12 Oct 2011 22 31
To: Tomcat Users List
Subject: RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com]
 Subject: RE: Application not logging out properly

 I would rather avoid forcing the browser to reload each page via the 
 appropriate headers.

Then they're going to be available in the browser cache until the browser
chooses to discard them.  You can't have it both ways.

 - Chuck


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


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




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

Re: Application not logging out properly

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/12/2011 5:30 PM, Caldarale, Charles R wrote:
 From: Martin O'Shea [mailto:app...@dsl.pipex.com] Subject: RE:
 Application not logging out properly
 
 I would rather avoid forcing the browser to reload each page via
 the appropriate headers.
 
 Then they're going to be available in the browser cache until the 
 browser chooses to discard them.  You can't have it both ways.

The OP could set expires headers that are relatively short-lived. That
way, the client /should/ request a fresh page after, say, 30 minutes
or whatever the session timeout is set to.

But Martin, I agree with Chuck: you can't have it both ways.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6WDZsACgkQ9CaO5/Lv0PCtGwCfdNJLAT8arkYg3n5TNrgtoFne
wFQAnAhmK2MqMBEMacc4a6zRAyTfKC/1
=s6fC
-END PGP SIGNATURE-

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

Re: Application not logging out properly

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 10/12/2011 5:58 PM, Martin O'Shea wrote:
 This is true of the current application, but also true of the other
 Tomcat applications I have.
 
 But the others don't seem to have this problem.

Which others?

 I know the sessions are invalidating because if I try to do 
 something on one of the pages visited in the session, the login
 page appears automatically.

You're getting all you can get out of the server-side of this
equation. You'll either have to use expires or other cache-control
headers or just trust your clients not to browse their caches.

 Using a filter to prevent caching does seem a sledgehammer
 approach. But I have set one up to do just that but I would prefer
 another solution.

I can't think of one.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6WDgQACgkQ9CaO5/Lv0PCVzgCeIl7RJkNgbXxNGFj7uJ671fXS
MQIAn2SH+d1iK3DumlNIOmMYAWsIF4f4
=MXp5
-END PGP SIGNATURE-

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

RE: Application not logging out properly

I'm not disagreeing and have set a filter to this end. But it doesn't explain 
why I can see the pages after session invalidation.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: 12 Oct 2011 22 59
To: Tomcat Users List
Subject: Re: Application not logging out properly

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chuck,

On 10/12/2011 5:30 PM, Caldarale, Charles R wrote:
 From: Martin O'Shea [mailto:app...@dsl.pipex.com] Subject: RE:
 Application not logging out properly

 I would rather avoid forcing the browser to reload each page via the 
 appropriate headers.

 Then they're going to be available in the browser cache until the 
 browser chooses to discard them.  You can't have it both ways.

The OP could set expires headers that are relatively short-lived. That way, the 
client /should/ request a fresh page after, say, 30 minutes or whatever the 
session timeout is set to.

But Martin, I agree with Chuck: you can't have it both ways.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6WDZsACgkQ9CaO5/Lv0PCtGwCfdNJLAT8arkYg3n5TNrgtoFne
wFQAnAhmK2MqMBEMacc4a6zRAyTfKC/1
=s6fC
-END PGP SIGNATURE-

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

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

Re: Application not logging out properly

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 10/12/2011 6:01 PM, Martin O'Shea wrote:
 I'm not disagreeing and have set a filter to this end. But it
 doesn't explain why I can see the pages after session
 invalidation.

Your web browser has an on-disk cache. It's reading the files from
there. If you watch your web server logs (or observe what the browser
does using httpfox, fiddler, etc.) you will likely see that there is no
server interaction whatsoever.

The client has no idea that the session has expired and that somehow,
it should expire all the pages in it's cache.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6WDs8ACgkQ9CaO5/Lv0PA7AACglHXo/DVOTXoXVR1eKbHgboFD
UUoAn0GH6FdBZLSJg24C853+SkzrEs+r
=Q+Ng
-END PGP SIGNATURE-

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

RE: Application not logging out properly

But I can see these pages visited in the session just invalidated by using the 
browser's back button after logging out.

By other Tomcat applications, I mean other applications which have the same 
arrangements and run under 6.0.26. But when I log out from one of these, I 
can't see pages just visited.

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: 12 Oct 2011 23 01
To: Tomcat Users List
Subject: Re: Application not logging out properly

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin,

On 10/12/2011 5:58 PM, Martin O'Shea wrote:
 This is true of the current application, but also true of the other 
 Tomcat applications I have.
 
 But the others don't seem to have this problem.

Which others?

 I know the sessions are invalidating because if I try to do something 
 on one of the pages visited in the session, the login page appears 
 automatically.

You're getting all you can get out of the server-side of this equation. You'll 
either have to use expires or other cache-control headers or just trust your 
clients not to browse their caches.

 Using a filter to prevent caching does seem a sledgehammer approach. 
 But I have set one up to do just that but I would prefer another 
 solution.

I can't think of one.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6WDgQACgkQ9CaO5/Lv0PCVzgCeIl7RJkNgbXxNGFj7uJ671fXS
MQIAn2SH+d1iK3DumlNIOmMYAWsIF4f4
=MXp5
-END PGP SIGNATURE-

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




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

RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com] 
 Subject: RE: Application not logging out properly

 But it doesn't explain why I can see the pages after session invalidation.

It certainly does.  If the browser (or some other intermediary) is caching the 
pages, they will be available for display.  Try sniffing the network traffic at 
both the browser and Tomcat ends to see who has the data.

 - Chuck

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

RE: Application not logging out properly

Well, there's no intermediary: I'm seeing this in NetBeans 7.0.1 with AT 
6.0.26. and if my NoCache_Filter contains this:

// Force browser not to cache pages.
HttpServletResponse hsr = (HttpServletResponse) response;   
  
hsr.setHeader(Cache-Control, no-cache, no-store, 
must-revalidate); // HTTP 1.1. 
hsr.setHeader(Pragma, no-cache); // HTTP 1.0. 
hsr.setDateHeader(Expires, 0); // Proxies.

With the settings in web.xml as follows:

filter-mapping
filter-nameNoCacheFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping

 So be it.

I can always edit the url-pattern to exclude certain pages anyway.

Thanks.


-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: 12 Oct 2011 23 05
To: Tomcat Users List
Subject: RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com] 
 Subject: RE: Application not logging out properly

 But it doesn't explain why I can see the pages after session invalidation.

It certainly does.  If the browser (or some other intermediary) is caching the 
pages, they will be available for display.  Try sniffing the network traffic at 
both the browser and Tomcat ends to see who has the data.

 - Chuck


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




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

Re: Tomcat connector for IIS, are user groups passed along?

2011-10-12 Thread chris derham


 - it would probably require serious coding changes to do it (notably
 because in the AJP protocol, there is no attribute or packet type foreseen
 to pass such information per se)
 - and there are some conceptual issues linked to this, essentially because
 the very notion  of AD/NTLM user groups is something valid only in an
 MS-centric context (and Tomcat has to work in other contexts).


Kerberos is cross platform standard, allowing for groups to be embedded in
the token. Nothing windows specific about that. I've definitely had windows
primary domain controller and clients running on Windows talking to a tomcat
running on Linux, and allowing access to the group info in the kerberos
tokens


 For another option, in Tomcat 7.x there is also a new SPNEGO authentication
 mechanism available, described here :
 http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#SPNEGO_Valve


SPNEGO is Simple Protocol for Negotiating Authentication (or something like
that). It basically causes a Kerberos token to be added via a http header
called  authentication. I don't know anything about the ISAPI connector, but
if it could pass through the authentication header with the kerberos token,
then tomcat side you can decode the kerberos token and access the users
groups. So that should work, and should work at no cost - well you'll need
to spend some time configuring it and getting accounts setup, but should be
easy enough.

HTH

Chris

RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com] 
 Subject: RE: Application not logging out properly

 But I can see these pages visited in the session just invalidated 
 by using the browser's back button after logging out.

The session state is completely irrelevant - the browser knows nothing about 
it.  Again, it looks like the browser is caching the pages.

 By other Tomcat applications, I mean other applications which have 
 the same arrangements and run under 6.0.26. But when I log out from
 one of these, I can't see pages just visited.

Sniff the network traffic or use one of the plugins Chris suggested to see 
what's different about the pages that aren't getting cached.  (Using HTTPS, 
perhaps?)

 - Chuck

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

RE: Application not logging out properly

Not HTTPS but it worth me checking as you advise.

-Original Message-
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] 
Sent: 12 Oct 2011 23 16
To: Tomcat Users List
Subject: RE: Application not logging out properly

 From: Martin O'Shea [mailto:app...@dsl.pipex.com]
 Subject: RE: Application not logging out properly

 But I can see these pages visited in the session just invalidated by 
 using the browser's back button after logging out.

The session state is completely irrelevant - the browser knows nothing about 
it.  Again, it looks like the browser is caching the pages.

 By other Tomcat applications, I mean other applications which have the 
 same arrangements and run under 6.0.26. But when I log out from one of 
 these, I can't see pages just visited.

Sniff the network traffic or use one of the plugins Chris suggested to see 
what's different about the pages that aren't getting cached.  (Using HTTPS, 
perhaps?)

 - Chuck

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

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

Re: Application not logging out properly

2011-10-12 Thread chris derham

 Then they're going to be available in the browser cache until the
 browser chooses to discard them.  You can't have it both ways.

The OP could set expires headers that are relatively short-lived. That
way, the client /should/ request a fresh page after, say, 30 minutes
or whatever the session timeout is set to.

But Martin, I agree with Chuck: you can't have it both ways.

I was going to suggest that you could use the ETag to create tags composed
of the last edit time and the session-id. That way the pages will be cached
for the current user's session, but are freshed once the user logs
out/original page is updated. Its not true caching in that the browser will
still ask the server if it has changed, but at least it won't have to send
the whole file down each time.

Seems that the thread has moved on now though. If I understood correctly you
have turned off all caching, yet the pages are still cached. I agree with
the others - try using some tools to sniff the actual network traffic. I
find fiddler very useful for this kind of work

Chris

RE: Application not logging out properly