Re: Emulating JServ's session.topleveldomain with Catalina

[Craig R. McClanahan]

I'd certainly be interested in a patch to allow pattern matching in the
host mapper, as long as the code was smart about using direct string
compares when no patterns are specified (to avoid slowing down all
requests by regexp processing).

Note that Tomcat already loads jakarta-regexp for use in the
RemoteAddrValve and RemoteHostValve filters.  If you need regexp patterns,
that would be a convenient choice because no additional dependencies would
be created.

Craig


On Thu, 29 Nov 2001, Daniel Rall wrote:

> Date: Thu, 29 Nov 2001 13:33:17 -0800
> From: Daniel Rall <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Emulating JServ's session.topleveldomain with Catalina
>
> "Craig R. McClanahan" <[EMAIL PROTECTED]> writes:
>
> > On Sat, 24 Nov 2001, Daniel Rall wrote:
> >
> >> "Craig R. McClanahan" <[EMAIL PROTECTED]> writes:
> >>
> >> > On Wed, 21 Nov 2001, Daniel Rall wrote:
> >> >
> >> >> Using Tomcat 4.0.1, is there any way to emulate JServ's
> >> >> session.topleveldomain context configuration?
> >> >>
> >> >> # Set the domain= header that gets sent with the cookie. This is
> >> >> # entirely optional
> >> >> # Default: null
> >> >> # this is needed when we vhost to avoid multiple login
> >> >> session.topleveldomain=.foo.com
> >> >>
> >> >> I would like all requests to the set of virtual hosts represented by
> >> >> the glob *.foo.com to share the same session ID.
> >> >
> >> > Unfortunately, implementing this functionality would violate the Servlet
> >> > spec's requirements about sessions being scoped to a single
> >> > ServletContext.  Even if you were willing to do this, you're going to run
> >> > into lots of technical problems due to the fact that each webapp is loaded
> >> > by it's own classloader -- trying to access a session attribute loaded
> >> > from a different webapp will throw ClassNotFoundException errors at you.
> >>
> >> I wasn't clear enough in my original query --  I don't want to scope
> >> one session to multiple contexts, but to a single context accessed by
> >> multiple host names which correspond to the same physical host (the
> >> default host in server.xml).
> >
> > This is still illegal based on the same rule - each virtual host has its
> > own set of webapps.  Tomcat 4 is built on this assumption.
>
> Using the distinction you mention below, the host name used in the
> request is merely a host alias (rather than a virtual host).
>
> > One way to work around it (with Tomcat 4) would be to use the "host
> > aliasing" capability, where you say that a set of host names really refer
> > to the same virtual host.  This was primarily intended to deal with cases
> > like "company.com" and "www.company.com" resolving to the same app, but
> > could actually be used for more than that.  Check out the 
> > directive (in server.xml).
>
> Thanks for suggesting a work around, Craig (I'm only concerned with
> Tomcat 4 ATM =).
>
> Reviewing the implementation of the  directive in
> StandardEngineMapper and FastEngineMapper, it appears that only
> literal mappings are provided for (i.e. wildcards are not allowed
> supported).
>
> I have a requirement of supporting addition of host alias mappings at
> run-time, but neither see a way to reload server.xml nor have much of
> a desire to modify it from servlet code.  Is there another way to
> handle this situation?  If not, would the Catalina developers be
> amenable to a patch which adds wildcard capability to the host alias
> feature?  Would regex or file system-style globs be preferred (I lean
> towards the latter)?  If this is undesirable, what are my options
> (i.e. can I configure my Engine entry in server.xml to use a custom
> Mapper)?
>
>
> Thanks, Daniel
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Emulating JServ's session.topleveldomain with Catalina

[Daniel Rall]

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:

> On Sat, 24 Nov 2001, Daniel Rall wrote:
>
>> "Craig R. McClanahan" <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, 21 Nov 2001, Daniel Rall wrote:
>> >
>> >> Using Tomcat 4.0.1, is there any way to emulate JServ's
>> >> session.topleveldomain context configuration?
>> >>
>> >> # Set the domain= header that gets sent with the cookie. This is
>> >> # entirely optional
>> >> # Default: null
>> >> # this is needed when we vhost to avoid multiple login
>> >> session.topleveldomain=.foo.com
>> >>
>> >> I would like all requests to the set of virtual hosts represented by
>> >> the glob *.foo.com to share the same session ID.
>> >
>> > Unfortunately, implementing this functionality would violate the Servlet
>> > spec's requirements about sessions being scoped to a single
>> > ServletContext.  Even if you were willing to do this, you're going to run
>> > into lots of technical problems due to the fact that each webapp is loaded
>> > by it's own classloader -- trying to access a session attribute loaded
>> > from a different webapp will throw ClassNotFoundException errors at you.
>>
>> I wasn't clear enough in my original query --  I don't want to scope
>> one session to multiple contexts, but to a single context accessed by
>> multiple host names which correspond to the same physical host (the
>> default host in server.xml).
>
> This is still illegal based on the same rule - each virtual host has its
> own set of webapps.  Tomcat 4 is built on this assumption.

Using the distinction you mention below, the host name used in the
request is merely a host alias (rather than a virtual host).

> One way to work around it (with Tomcat 4) would be to use the "host
> aliasing" capability, where you say that a set of host names really refer
> to the same virtual host.  This was primarily intended to deal with cases
> like "company.com" and "www.company.com" resolving to the same app, but
> could actually be used for more than that.  Check out the 
> directive (in server.xml).

Thanks for suggesting a work around, Craig (I'm only concerned with
Tomcat 4 ATM =).

Reviewing the implementation of the  directive in
StandardEngineMapper and FastEngineMapper, it appears that only
literal mappings are provided for (i.e. wildcards are not allowed
supported).

I have a requirement of supporting addition of host alias mappings at
run-time, but neither see a way to reload server.xml nor have much of
a desire to modify it from servlet code.  Is there another way to
handle this situation?  If not, would the Catalina developers be
amenable to a patch which adds wildcard capability to the host alias
feature?  Would regex or file system-style globs be preferred (I lean
towards the latter)?  If this is undesirable, what are my options
(i.e. can I configure my Engine entry in server.xml to use a custom
Mapper)?


Thanks, Daniel

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Emulating JServ's session.topleveldomain with Catalina

[Daniel Rall]

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:

> I'd certainly be interested in a patch to allow pattern matching in the
> host mapper, as long as the code was smart about using direct string
> compares when no patterns are specified (to avoid slowing down all
> requests by regexp processing).

Since "." is a regex character, there is no way to automatically infer
whether an alias string is a pattern or a literal, meaning that a way
to communicate to the Mapper implementations which aliases are
patterns is required.  Because of this, I don't believe that it is
possible to avoid minor API/server.xml additions/changes.

The cleanest implementation route I see for addition of pattern
matching is to solidfy an existing data type (Alias) as an interface
accompanied by standard implementation.  The suggested syntax would be
as follows:


  .*domain.com
  
  www.otherdomain.com


I haven't previously used Digester, Modeler, or BeanUtils, so am
unsure of what changes to make to mbeans-descriptors.xml and
HostRuleSet.java (I definitely screwed up the declaration for Alias).

> Note that Tomcat already loads jakarta-regexp for use in the
> RemoteAddrValve and RemoteHostValve filters.  If you need regexp patterns,
> that would be a convenient choice because no additional dependencies would
> be created.

Gotcha -- I used RE.match() in the style of RequestFilterValve.

Here's an incomplete version of the modifications to solicit feedback,
and make sure I'm following the desired path:


Index: src/share/org/apache/catalina/Alias.java
===
RCS file: Alias.java
diff -N Alias.java
--- /dev/null   Fri Nov 30 17:57:31 2001
+++ Alias.java  Fri Nov 30 17:59:22 2001
@@ -0,0 +1,128 @@
+/*
+ * $Header: 
+/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Host.java,v 
+1.7 2001/10/22 04:48:56 remm Exp $
+ * $Revision: 1.7 $
+ * $Date: 2001/10/22 04:48:56 $
+ *
+ * 
+ *
+ * The Apache Software License, Version 1.1
+ *
+ * Copyright (c) 1999 The Apache Software Foundation.  All rights
+ * reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in
+ *the documentation and/or other materials provided with the
+ *distribution.
+ *
+ * 3. The end-user documentation included with the redistribution, if
+ *any, must include the following acknowlegement:
+ *   "This product includes software developed by the
+ *Apache Software Foundation (http://www.apache.org/)."
+ *Alternately, this acknowlegement may appear in the software itself,
+ *if and wherever such third-party acknowlegements normally appear.
+ *
+ * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
+ *Foundation" must not be used to endorse or promote products derived
+ *from this software without prior written permission. For written
+ *permission, please contact [EMAIL PROTECTED]
+ *
+ * 5. Products derived from this software may not be called "Apache"
+ *nor may "Apache" appear in their names without prior written
+ *permission of the Apache Group.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ * 
+ *
+ * This software consists of voluntary contributions made by many
+ * individuals on behalf of the Apache Software Foundation.  For more
+ * information on the Apache Software Foundation, please see
+ * .
+ *
+ */
+
+
+package org.apache.catalina;
+
+
+import javax.servlet.ServletContext;
+
+/**
+ * An Alias defines a mapping from a host name used in a
+ * request to a Host object from server.xml.
+ *
+ * @author mailto:[EMAIL PROTECTED]";>Daniel Rall
+ * @version $Revision: $ $Date: $
+ */
+
+public interface Alias {
+
+
+// ---

Re: Emulating JServ's session.topleveldomain with Catalina

[Daniel Rall]

[This was originally sent to tomcat-user, but is probably better
discussed on tomcat-dev.]

Why does the Valve implementation at the bottom of this message never
print out any session cookies?

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:

> On Wed, 21 Nov 2001, Daniel Rall wrote:
>
>> Using Tomcat 4.0.1, is there any way to emulate JServ's
>> session.topleveldomain context configuration?
>>
>> # Set the domain= header that gets sent with the cookie. This is
>> # entirely optional
>> # Default: null
>> # this is needed when we vhost to avoid multiple login
>> session.topleveldomain=.foo.com
>>
>> I would like all requests to the set of virtual hosts represented by
>> the glob *.foo.com to share the same session ID.
>
> Unfortunately, implementing this functionality would violate the Servlet
> spec's requirements about sessions being scoped to a single
> ServletContext.  Even if you were willing to do this, you're going to run
> into lots of technical problems due to the fact that each webapp is loaded
> by it's own classloader -- trying to access a session attribute loaded
> from a different webapp will throw ClassNotFoundException errors at you.

I wasn't clear enough in my original query -- I don't want to scope
one session to multiple contexts, but to a single context accessed by
multiple host names which correspond to the same physical host (the
default host in server.xml).

So, if the DNS for both baz.foo.com and bar.foo.com resolves to the
same IP, a request to /myapp for baz.foo.com will create a session
with a JSESSIONID cookie domain of .foo.com, allowing requests to
bar.foo.com (or any other DNS mappings) to /myapp servlet context to
share the same HttpSession.

I took a stab at implementing this as a , with some success.
My original thought was to groom the JSESSIONID cookies in the request
and response -- however, they never seem to show up (i.e. I never have
any cookies available from HttpRequest::getCookies() or
HttpResponse::getCookies()).  Perhaps I just attached the Valve at the
wrong spot (in the config file)?  Because I haven't been able to
access the JSESSIONID cookies, I end up getting a two cookies written
on the original request, one for the first host requested
(baz.foo.com), and another from my Valve for .foo.com (also from the
first request).  I get the desired result from this (unfortunately
with an extra cookie set for baz.foo.com), but am curious why I those
JSESSIONID cookies haven't turned up.

Any comments would be appreciated.

Dan


/*
 * $Header: $
 * $Revision: $
 * $Date: $
 *
 * 
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 1999 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in
 *the documentation and/or other materials provided with the
 *distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *any, must include the following acknowlegement:
 *   "This product includes software developed by the
 *Apache Software Foundation (http://www.apache.org/)."
 *Alternately, this acknowlegement may appear in the software itself,
 *if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *Foundation" must not be used to endorse or promote products derived
 *from this software without prior written permission. For written
 *permission, please contact [EMAIL PROTECTED]
 *
 * 5. Products derived from this software may not be called "Apache"
 *nor may "Apache" appear in their names without prior written
 *permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * 
 *
 * This software con

Re: Emulating JServ's session.topleveldomain with Catalina

[Daniel Rall]

"Craig R. McClanahan" <[EMAIL PROTECTED]> writes:

> I'd certainly be interested in a patch to allow pattern matching in the
> host mapper, as long as the code was smart about using direct string
> compares when no patterns are specified (to avoid slowing down all
> requests by regexp processing).
>
> Note that Tomcat already loads jakarta-regexp for use in the
> RemoteAddrValve and RemoteHostValve filters.  If you need regexp patterns,
> that would be a convenient choice because no additional dependencies would
> be created.

Hi Craig.  Did you have a chance to look over my initial rev of the
patch to add pattern matching to the host mapper?  Is the Alias change
acceptable?  (Sorry if you already responded -- I've been off-line.
My ATT@Home service was temporarily down after Excite declared chapter
11.)

If so, would you comment on how to get the Digester/Modeler to
properly configure an Alias object?  I could use some guidance with
that.

If not, how would you suggest I proceed to make such a patch
acceptable (i.e. what other constraints should I take into account)?


 Thanks, Dan

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Emulating JServ's session.topleveldomain with Catalina

[Daniel Rall]

Daniel Rall <[EMAIL PROTECTED]> writes:

> [This was originally sent to tomcat-user, but is probably better
> discussed on tomcat-dev.]
>
> Why does the Valve implementation at the bottom of this message never
> print out any session cookies?

To answer myself (as addressed by my recent patch), because the
session cookie is added via the sendHeaders() method of
HttpResponseBase AFTER the Pipeline finishes processing.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: