I had another look at this and I think this has to be the only way... short
of writing the authentication code ourselves.
For it to work you must have
<login-config>
<security-constraint>
stuff in you web.xml file.... ie if the page is not protected, its not going
to start working... and it will "only" start working when the user logs in
to some page.
Then in every hosts section we do this....
<Host name="test1.localhost.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Valve
className="org.apache.catalina.authenticator.SingleSignOn"
cookieDomain=".gangbang.com"/>
</Host>
<Host name="test2.localhost.com" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Valve
className="org.apache.catalina.authenticator.SingleSignOn"
cookieDomain=".gangbang.com"/>
</Host>
So... as soon as someone logs in to a protected page.... only then should
you a see a cookie in the header being set to .gangbang.com
And to test.... you can set
127.0.0.1 test1.localhost.com
127.0.0.1 test2.localhost.com
in the computers "hosts" file... easier than trying to set up a dns to test
Then log in to test1.localhost.com page and swap it to test2.localhost.com
and see if the user has to relog in.
So as soon as a user logs in you should see a cookie in the header whose
domain name is being set as ".gangbang.com" but "only" when they log in.
And because the user has the same role name.... the same session ID should
be used and thus the browser treats all the webapps as one.
I dont think it really matters what the cookieDomain is set to as long as
its the same for all the host names you using... it will be enough to trick
the browser...
Of course what may snooker us in the end is IE's security.... might complain
that hostname being set in cookie is not the same as actual host name... but
then you know its working and can change gangbang to ".domain.com"
This HAS to work..... if it doesnt it means we have to write the code, and
not use tomcats authentication.... it must work or its going to be max work.
Wish the documentation explained the actual mechanism a little better....
but I think we onto the right idea...
Have fun.....
----- Original Message -----
From: "Jeremy Cowgar" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <users@tomcat.apache.org>
Sent: Saturday, April 21, 2007 5:50 PM
Subject: Re: Session across multiple hosts?
Unfortunately that did not work. The cookie still got set as domain.com,
not .domain.com
I have in server.xml:
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
<Valve className="org.apache.catalina.authenticator.SingleSignOn"
cookieDomain=".localhost"/>
</Host>
</Engine>
Now, this is still in development, thus the localhost, and I've defined
many other "hostnames" in my hosts file, like host1.localhost,
host2.localhost, host3.localhost. My app is working great and responding
to those correctly, but the cookie is being set as localhost, not
.localhost.
Jeremy
On Apr 21, 2007, at 11:30 AM, Johnny Kewl wrote:
So.... if you want to get the browser to treat the 2 domain names the
same.... you have to SOMEHOW set the domain in that JSession cookie.
Tomcat will automatically set it to abc.domain.com and
def.domain.com.....
but
you need to make it set BOTH machines to ".domain.com".
<
Valve className="org.apache.catalina.authenticator.SingleSignOn"
cookieDomain=".domain.com"
/>
Greetings!
I have domain.com and my app uses hosts under that domain, like
abc.domain.com, def.domain.com... When the user logs in, the session
is valid only on domain.com... How can I make that session also valid
under the other hostnames?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
