You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Phillip Rhodes <rh...@telerama.com> on 2002/09/28 19:51:18 UTC
filter to change jsessionid cookie almost done, but need
little help
I am writing a package that will facilitate sso between java based
applications that will be released open source and free.
Part of the problem is that the tomcat cookie name is NOT at all
configurable.
When jsessionid is set, the host of the domain is present, the scope is set
to the webapp, etc...
I wrote a filter that reads the jsessionid and change the scope and domain
that it can be read by any application in that domain.
My problem is that in the first request in my filter (and to the app), the
cookie may not be set.
No problem (or so i thought!) . I created a HttpResponseWrapper and
HttpRequestWrapper and pass that onto the filter chain.
When someone calls addCookie on the response (my wrapper) , I put in in my
requestwrapper, so I can read cookies that are set in the present
request/response.
After I do the filter.doChain method, I again check for the jsessionid
cookie. It's not set in the HttpRequestWrapper that I passed onto the
chain, but I DO know it's being set by the time my browser gets it.
Here is the Code:
http://test.rhoderunner.com/jsso/src/com/rhoderunner/jsso/SSOCookieFilter.java
http://test.rhoderunner.com/jsso/src/com/rhoderunner/jsso/SSORequestWrapper.java
http://test.rhoderunner.com/jsso/src/com/rhoderunner/jsso/SSOResponseWrapper.java
Here you can even test it! Turn on cookie notification. The jsessionid is
set as usual. Do a refresh of the page, and you will see the new
jsessionid cookie! I want my new cookie to be the one that's first set. I
don't want to have to do a refresh (or go to another page).
http://test.rhoderunner.com/jetspeed/ssocookiefilter/index.jsp this url
may be done periodically, it's my test box.
Thanks. I hope my sso solution helps folks when complete. This is just
part of it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: filter to change jsessionid cookie almost done, but need little
help
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 30 Sep 2002 rhodespc@telerama.com wrote:
> Date: Mon, 30 Sep 2002 12:53:54 -0400 (EDT)
> From: rhodespc@telerama.com
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: filter to change jsessionid cookie almost done,
> but need little help
>
>
> The Tomcat sso solution only allows sso between applications in a single
> container. My sso solution allows sso across multiple jvm's in
> different hosts in the same domain, as well as the SSO for the single JVM.
>
> The SSO for tomcat is quite limited.
>
> I agree that the jsessionid is part of the spec, we agree with all specs,
> right? But we can have cookie name collisions if you try to raise the
> scope/domain of the jsessionid cookie.
>
That's why the container deliberately sets the jsessionid properties the
way that it does.
> My original problem is that I am not able to intercept the setting of the
> jsessionid cookie in my filter. Can you provide any guidance on how I may
> intercept this event?
>
You cannot intercept this in a filter, because it is being done by the
container. At best, you'd have to write a Valve to do it inside Tomcat,
or otherwise modify the Tomcat source code. Obviously, you become
container dependent at this point, but that's going to be true of any
solution that actually modifies how container managed security works.
My primary advice still stands -- do NOT try to mess with the jsesssionid
cookie at all when implementing SSO type solutions. Use a separate cookie
instead.
> Thanks!
> Phillip
>
Craig
> On Sun, 29 Sep 2002, Craig R. McClanahan wrote:
>
> >
> >
> > On Sat, 28 Sep 2002, Phillip Rhodes wrote:
> >
> > > Date: Sat, 28 Sep 2002 13:51:18 -0400
> > > From: Phillip Rhodes <rh...@telerama.com>
> > > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > > To: tomcat-user@jakarta.apache.org
> > > Subject: filter to change jsessionid cookie almost done,
> > > but need little help
> > >
> > > I am writing a package that will facilitate sso between java based
> > > applications that will be released open source and free.
> > >
> >
> > You might also consider just using the single sign on support provided by
> > your container. For Tomcat 4, see the documentation at:
> >
> > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html
> >
> > and scroll down to the section entitled "Single Sign On".
> >
> > > Part of the problem is that the tomcat cookie name is NOT at all
> > > configurable.
> > > When jsessionid is set, the host of the domain is present, the scope is set
> > > to the webapp, etc...
> > >
> >
> > The cookie name is standardized by the servlet spec -- there is no reason
> > to make it configurable.
> >
> > > I wrote a filter that reads the jsessionid and change the scope and domain
> > > that it can be read by any application in that domain.
> > > My problem is that in the first request in my filter (and to the app), the
> > > cookie may not be set.
> > > No problem (or so i thought!) . I created a HttpResponseWrapper and
> > > HttpRequestWrapper and pass that onto the filter chain.
> > > When someone calls addCookie on the response (my wrapper) , I put in in my
> > > requestwrapper, so I can read cookies that are set in the present
> > > request/response.
> > > After I do the filter.doChain method, I again check for the jsessionid
> > > cookie. It's not set in the HttpRequestWrapper that I passed onto the
> > > chain, but I DO know it's being set by the time my browser gets it.
> > >
> >
> > IMHO, you are following the wrong strategy. It's perfectly reasonable to
> > support single sign on across apps that have independent sessions (and
> > even apps that don't involve sessions at all). The Tomcat implementation
> > accomplishes SSO with a separate cookie.
> >
> > Craig
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: filter to change jsessionid cookie almost done, but need
little help
Posted by rh...@telerama.com.
The Tomcat sso solution only allows sso between applications in a single
container. My sso solution allows sso across multiple jvm's in
different hosts in the same domain, as well as the SSO for the single JVM.
The SSO for tomcat is quite limited.
I agree that the jsessionid is part of the spec, we agree with all specs,
right? But we can have cookie name collisions if you try to raise the
scope/domain of the jsessionid cookie.
My original problem is that I am not able to intercept the setting of the
jsessionid cookie in my filter. Can you provide any guidance on how I may
intercept this event?
Thanks!
Phillip
On Sun, 29 Sep 2002, Craig R. McClanahan wrote:
>
>
> On Sat, 28 Sep 2002, Phillip Rhodes wrote:
>
> > Date: Sat, 28 Sep 2002 13:51:18 -0400
> > From: Phillip Rhodes <rh...@telerama.com>
> > Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> > To: tomcat-user@jakarta.apache.org
> > Subject: filter to change jsessionid cookie almost done,
> > but need little help
> >
> > I am writing a package that will facilitate sso between java based
> > applications that will be released open source and free.
> >
>
> You might also consider just using the single sign on support provided by
> your container. For Tomcat 4, see the documentation at:
>
> http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html
>
> and scroll down to the section entitled "Single Sign On".
>
> > Part of the problem is that the tomcat cookie name is NOT at all
> > configurable.
> > When jsessionid is set, the host of the domain is present, the scope is set
> > to the webapp, etc...
> >
>
> The cookie name is standardized by the servlet spec -- there is no reason
> to make it configurable.
>
> > I wrote a filter that reads the jsessionid and change the scope and domain
> > that it can be read by any application in that domain.
> > My problem is that in the first request in my filter (and to the app), the
> > cookie may not be set.
> > No problem (or so i thought!) . I created a HttpResponseWrapper and
> > HttpRequestWrapper and pass that onto the filter chain.
> > When someone calls addCookie on the response (my wrapper) , I put in in my
> > requestwrapper, so I can read cookies that are set in the present
> > request/response.
> > After I do the filter.doChain method, I again check for the jsessionid
> > cookie. It's not set in the HttpRequestWrapper that I passed onto the
> > chain, but I DO know it's being set by the time my browser gets it.
> >
>
> IMHO, you are following the wrong strategy. It's perfectly reasonable to
> support single sign on across apps that have independent sessions (and
> even apps that don't involve sessions at all). The Tomcat implementation
> accomplishes SSO with a separate cookie.
>
> Craig
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: filter to change jsessionid cookie almost done, but need little
help
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 28 Sep 2002, Phillip Rhodes wrote:
> Date: Sat, 28 Sep 2002 13:51:18 -0400
> From: Phillip Rhodes <rh...@telerama.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: filter to change jsessionid cookie almost done,
> but need little help
>
> I am writing a package that will facilitate sso between java based
> applications that will be released open source and free.
>
You might also consider just using the single sign on support provided by
your container. For Tomcat 4, see the documentation at:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html
and scroll down to the section entitled "Single Sign On".
> Part of the problem is that the tomcat cookie name is NOT at all
> configurable.
> When jsessionid is set, the host of the domain is present, the scope is set
> to the webapp, etc...
>
The cookie name is standardized by the servlet spec -- there is no reason
to make it configurable.
> I wrote a filter that reads the jsessionid and change the scope and domain
> that it can be read by any application in that domain.
> My problem is that in the first request in my filter (and to the app), the
> cookie may not be set.
> No problem (or so i thought!) . I created a HttpResponseWrapper and
> HttpRequestWrapper and pass that onto the filter chain.
> When someone calls addCookie on the response (my wrapper) , I put in in my
> requestwrapper, so I can read cookies that are set in the present
> request/response.
> After I do the filter.doChain method, I again check for the jsessionid
> cookie. It's not set in the HttpRequestWrapper that I passed onto the
> chain, but I DO know it's being set by the time my browser gets it.
>
IMHO, you are following the wrong strategy. It's perfectly reasonable to
support single sign on across apps that have independent sessions (and
even apps that don't involve sessions at all). The Tomcat implementation
accomplishes SSO with a separate cookie.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>