You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Oscar Picasso <os...@yahoo.com> on 2004/10/26 19:27:10 UTC
Sharing sessions and authentication across sites
Hi,
I have a cocoon application that serves different sites.
For example:
htpp://first.com
htpp://second.com
htpp://third.com
A request to any of the site is handled by the same sitemap hierarchy. Each of
the site specific snippet is handled either by using an XXHost matcher, or by
testing the real requested site inside XSP pages etc.
Each of the site has protected and unprotected sections.
While surfing, we need to keep track of some user preferences. For the moment,
I use sessions to keep track of these user preferences.
>From each site, there are links that point to the other sites. I would like to
share tbe user preferences accross the different sites.
Is there a mean to share sessions accross these different sites?
More importantly, in each site their is the ability for a user to login. I
would like the authentication to be shared across the sites, so that when one
user is logged in one site, it would be logged for every other site.
Any idea?
Thanks.
Oscar
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sharing sessions and authentication across sites [SOLVED]
Posted by Oscar Picasso <os...@yahoo.com>.
I finally found a solution.
Sessions and authentication are shared between sites that use a same cocoon
instance. The problems lies in the access to the session id cookie.
Let's say we have:
first.mydomain.org
second.mydomain.org
I just had added the following in web.xml
<context-param>
<param-name>org.mortbay.jetty.servlet.SessionPath</param-name>
<param-value>/</param-value>
</context-param>
<context-param>
<param-name>org.mortbay.jetty.servlet.SessionDomain</param-name>
<param-value>.mydomain.org</param-value>
</context-param>
Now evevry *.mydomain.org 'site' will get the same session id cookie and
sessions will be shared across these sites.
The configuration above is Jetty specific and there is no need to use Apache.
--- Oscar Picasso <os...@yahoo.com> wrote:
> > If you have "different sites" under the same webserver
> > installation then sharing the authentication information
> > between cocoon apps should be ok.
>
> That's my configuration. It should be ok but in my case it's not.
>
> So let me detail my config.
>
> Both the server and the client I use to test have the following line in
> /etc/hosts:
> 192.168.1.2 first.org second.org
>
> On the server I use one application server (Jetty) with one cocoon.war in the
> webapps folder. Its web-jetty.xml has:
> <Configure class="org.mortbay.jetty.servlet.WebApplicationContext">
> <Set name="ContextPath">/</Set>
> </Configure>
>
> So if I try to http://first.org or http://second.org it actually point to the
> same cocoon instance and sitemap.
>
> In the site map I have something like this:
> <map:match pattern="test">
> <map:act type="auth-protect">
> <map:parameter name="handler" value="managehandler"/>
> <map:generate type="serverpages" src="test/test.xsp"/>
> <map:serialize type="xml"/>
> </map:act>
> </map:match>
>
> The first time I try http://first.org, I get the login form and then the test
> page. The second time, I go directly to the test page. So the the
> authentication works fine with this domain.
>
> If after that, I try http://second.org, I get the login form again. The next
> time, I go directly to the test page. So here again the authentication works
> fine "inside" the second domain.
>
> The problem is that the authentication done in the first domain is not
> available for the second domain.
>
> When looking at the cookies manager, I have noticed that it has set one
> JSESSIONID for first.org and a different one for second.org. I guess that the
> problem lies here.
>
> On the cocoon web.xml file I have noticed the following lines:
>
> !-- Context Configuration ========================================== -->
>
> !--+
> | Set a context property useful to allow you to ProxyPass your
> | web application mounted to a different URI without loosing the
> | ability to do cookie-based sessions.
> | WARNING: this is Jetty specific!
> +-->
> !--context-param>
> <param-name>org.mortbay.jetty.servlet.SessionPath</param-name>
> <param-value>/some/path/to/your/webapp</param-value>
> <description>An override of the session cookie path</description>
> </context-param-->
>
> I thought it was somewhat related to my problem and tried to play with this
> param, but without success.
>
> I think, I have to configure something in Jetty and/or use apache but don't
> know where to start.
>
> I someone had a working Jetty (and/or apache) configuration example, I would
> greatly appreciate.
>
> Thanks.
>
> Oscar
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
_______________________________
Do you Yahoo!?
Express yourself with Y! Messenger! Free. Download now.
http://messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sharing sessions and authentication across sites
Posted by Oscar Picasso <os...@yahoo.com>.
> If you have "different sites" under the same webserver
> installation then sharing the authentication information
> between cocoon apps should be ok.
That's my configuration. It should be ok but in my case it's not.
So let me detail my config.
Both the server and the client I use to test have the following line in
/etc/hosts:
192.168.1.2 first.org second.org
On the server I use one application server (Jetty) with one cocoon.war in the
webapps folder. Its web-jetty.xml has:
<Configure class="org.mortbay.jetty.servlet.WebApplicationContext">
<Set name="ContextPath">/</Set>
</Configure>
So if I try to http://first.org or http://second.org it actually point to the
same cocoon instance and sitemap.
In the site map I have something like this:
<map:match pattern="test">
<map:act type="auth-protect">
<map:parameter name="handler" value="managehandler"/>
<map:generate type="serverpages" src="test/test.xsp"/>
<map:serialize type="xml"/>
</map:act>
</map:match>
The first time I try http://first.org, I get the login form and then the test
page. The second time, I go directly to the test page. So the the
authentication works fine with this domain.
If after that, I try http://second.org, I get the login form again. The next
time, I go directly to the test page. So here again the authentication works
fine "inside" the second domain.
The problem is that the authentication done in the first domain is not
available for the second domain.
When looking at the cookies manager, I have noticed that it has set one
JSESSIONID for first.org and a different one for second.org. I guess that the
problem lies here.
On the cocoon web.xml file I have noticed the following lines:
!-- Context Configuration ========================================== -->
!--+
| Set a context property useful to allow you to ProxyPass your
| web application mounted to a different URI without loosing the
| ability to do cookie-based sessions.
| WARNING: this is Jetty specific!
+-->
!--context-param>
<param-name>org.mortbay.jetty.servlet.SessionPath</param-name>
<param-value>/some/path/to/your/webapp</param-value>
<description>An override of the session cookie path</description>
</context-param-->
I thought it was somewhat related to my problem and tried to play with this
param, but without success.
I think, I have to configure something in Jetty and/or use apache but don't
know where to start.
I someone had a working Jetty (and/or apache) configuration example, I would
greatly appreciate.
Thanks.
Oscar
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sharing sessions and authentication across sites
Posted by Oscar Picasso <os...@yahoo.com>.
Thanks for the idea.
Actually I don't use apache httpd, but something that should behave similarly I
think.
I have only one servlet webapp (actually the cocoon instance) which already
serves the requests to the different sites.
The problem is that, even if the different sites are served by the same
servlet, the session and authentication is lost while going from one site to
another.
It seems that the session scope remains inside a requested site. By the way, if
I use cookies to keep track of the session I notice that the session id depends
on the requested site (one site cannot read the cookie from another site).
So I don't see how the session could be shared either with my actual
configuration or with your proposal.
Did I misunderstood what you wrote?
> Use Apache httpd in front of your servlet engine and have mod_proxy pipe
> the requests from httpd to 1 servlet webapp. The session can remain in
> Tomcat while Cocoon uses different stylings or sub sitemaps.
>
> Just a thought.
>
> Bert
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sharing sessions and authentication across sites
Posted by Bert Van Kets <co...@vankets.com>.
Use Apache httpd in front of your servlet engine and have mod_proxy pipe
the requests from httpd to 1 servlet webapp. The session can remain in
Tomcat while Cocoon uses different stylings or sub sitemaps.
Just a thought.
Bert
On Tue, 2004-10-26 at 19:27, Oscar Picasso wrote:
> Hi,
>
> I have a cocoon application that serves different sites.
> For example:
> htpp://first.com
> htpp://second.com
> htpp://third.com
>
> A request to any of the site is handled by the same sitemap hierarchy. Each of
> the site specific snippet is handled either by using an XXHost matcher, or by
> testing the real requested site inside XSP pages etc.
>
> Each of the site has protected and unprotected sections.
>
> While surfing, we need to keep track of some user preferences. For the moment,
> I use sessions to keep track of these user preferences.
>
> >From each site, there are links that point to the other sites. I would like to
> share tbe user preferences accross the different sites.
>
> Is there a mean to share sessions accross these different sites?
>
> More importantly, in each site their is the ability for a user to login. I
> would like the authentication to be shared across the sites, so that when one
> user is logged in one site, it would be logged for every other site.
>
> Any idea?
>
> Thanks.
>
> Oscar
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and JDK 1.5
Posted by Ralph Goers <Ra...@dslextreme.com>.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109710228801931&w=2
and
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109691665429634&w=2
Bert Van Kets said:
> This "rant" is about Cocoon 2.1.5
>
> The biggest problem using JDK 1.5 is the use of "enum" in the source
> code. This variable or object name is not allowed any more as enum is a
> new type of variable in JDK 1.5.
> There are however still quite a lot of uses of "enum" in the Cocoon
> source.
>
> First I rebuilt Jakarta Common Lang to solve the package problem in the
> forms and Woody block. "enum" is part of the package and has been
> replaced with "enums". The current commons-lang-2.0.jar file still
> contains the old package name. I needed to get the CVS version from the
> commons project and create the new jar using the "enums" package. If
> people are interested I can set this on a public location.
>
> The next problem to tackle is the use of "enum" in many packages. When
> you use Eclipse, this is easily solved doing a search on "Enumeration
> enum" and then refactor "enum" to "enums". There's also an Itereation
> called "enum", so don't forget to search for that.
>
> Once you did these two bits, Cocoon 2.1.5 will compile perfectly and be
> very fast. I ran through the major samples and they all came up
> perfectly and very fast.
>
> Hope this helps somebody.
>
> Now, is the "enum" problem going to be solved with Cocoon 2.1.6?
>
>
> Bert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and JDK 1.5
Posted by Bert Van Kets <co...@vankets.com>.
Hi Antonio,
I did a CVS checkout today before I started with the attempt to compile
with JDK 1.5.0. So I can tell that the 2.1 branch of Cocoon certainly
does not comply with 1.5 yet.
The source=1.4 trick does not allow full optimization of the code so
should be avoided.
It's correct that some build files need to be adjusted. References from
JDK 1.3 need to be replaced with 1.5.
Bert
On Tue, 2004-10-26 at 20:57, Antonio Gallardo wrote:
> Hi Bert:
>
> Thnks for the effort. Please see this:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=30883
>
> I think the next release is soon.
>
> Best Regards,
>
> Antonio Gallardo
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [SPAM] Re: [SPAM] Re: Cocoon and JDK 1.5
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert Van Kets dijo:
> Thanks for clearing that up. I have been out of Cocoon for some time for
> personal reasons (divorce) and did miss the branching and sub
> versioning.
> I used Eclipse CVS to check out the Cocoon-2.1 HEAD. From what I
> understand from the link you posted I should get the BRANCH_2_1_X
> version.
Yep. This is the version you need to check out. This SVN version contain
all the changes for java 1.5
> Darn, back to the basics. :-(
Don't worry, it is normal. ;-)
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [SPAM] Re: Cocoon and JDK 1.5
Posted by Bert Van Kets <co...@vankets.com>.
Thanks for clearing that up. I have been out of Cocoon for some time for
personal reasons (divorce) and did miss the branching and sub
versioning.
I used Eclipse CVS to check out the Cocoon-2.1 HEAD. From what I
understand from the link you posted I should get the BRANCH_2_1_X
version.
Darn, back to the basics. :-(
On Wed, 2004-10-27 at 18:32, Antonio Gallardo wrote:
> Bert:
>
> I hope you saw the other mail with this link:
>
> http://wiki.apache.org/cocoon/SubversionMigration
>
> Best Regards,
>
> Antonio Gallardo
>
> Bert Van Kets dijo:
> > Your remarks are correct. I do read the dev list too.
> > It still forces people to get the CVS version of commons-lang and in the
> > 2.1 Branch certainly not all uses of the "enum" variable are replaced.
> > There are still 19 cases of the "enum" declaration.
> >
> > Bert
> >
> > On Tue, 2004-10-26 at 21:34, Ralph Goers wrote:
> >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109710228801931&w=2
> >> and
> >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109691665429634&w=2
> >>
> >> Bert Van Kets said:
> >> > This "rant" is about Cocoon 2.1.5
> >> >
> >> > The biggest problem using JDK 1.5 is the use of "enum" in the source
> >> > code. This variable or object name is not allowed any more as enum is
> >> a
> >> > new type of variable in JDK 1.5.
> >> > There are however still quite a lot of uses of "enum" in the Cocoon
> >> > source.
> >> >
> >> > First I rebuilt Jakarta Common Lang to solve the package problem in
> >> the
> >> > forms and Woody block. "enum" is part of the package and has been
> >> > replaced with "enums". The current commons-lang-2.0.jar file still
> >> > contains the old package name. I needed to get the CVS version from
> >> the
> >> > commons project and create the new jar using the "enums" package. If
> >> > people are interested I can set this on a public location.
> >> >
> >> > The next problem to tackle is the use of "enum" in many packages. When
> >> > you use Eclipse, this is easily solved doing a search on "Enumeration
> >> > enum" and then refactor "enum" to "enums". There's also an Itereation
> >> > called "enum", so don't forget to search for that.
> >> >
> >> > Once you did these two bits, Cocoon 2.1.5 will compile perfectly and
> >> be
> >> > very fast. I ran through the major samples and they all came up
> >> > perfectly and very fast.
> >> >
> >> > Hope this helps somebody.
> >> >
> >> > Now, is the "enum" problem going to be solved with Cocoon 2.1.6?
> >> >
> >> >
> >> > Bert
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> >> > For additional commands, e-mail: users-help@cocoon.apache.org
> >> >
> >> >
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: [SPAM] Re: Cocoon and JDK 1.5
Posted by Antonio Gallardo <ag...@agssa.net>.
Bert:
I hope you saw the other mail with this link:
http://wiki.apache.org/cocoon/SubversionMigration
Best Regards,
Antonio Gallardo
Bert Van Kets dijo:
> Your remarks are correct. I do read the dev list too.
> It still forces people to get the CVS version of commons-lang and in the
> 2.1 Branch certainly not all uses of the "enum" variable are replaced.
> There are still 19 cases of the "enum" declaration.
>
> Bert
>
> On Tue, 2004-10-26 at 21:34, Ralph Goers wrote:
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109710228801931&w=2
>> and
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109691665429634&w=2
>>
>> Bert Van Kets said:
>> > This "rant" is about Cocoon 2.1.5
>> >
>> > The biggest problem using JDK 1.5 is the use of "enum" in the source
>> > code. This variable or object name is not allowed any more as enum is
>> a
>> > new type of variable in JDK 1.5.
>> > There are however still quite a lot of uses of "enum" in the Cocoon
>> > source.
>> >
>> > First I rebuilt Jakarta Common Lang to solve the package problem in
>> the
>> > forms and Woody block. "enum" is part of the package and has been
>> > replaced with "enums". The current commons-lang-2.0.jar file still
>> > contains the old package name. I needed to get the CVS version from
>> the
>> > commons project and create the new jar using the "enums" package. If
>> > people are interested I can set this on a public location.
>> >
>> > The next problem to tackle is the use of "enum" in many packages. When
>> > you use Eclipse, this is easily solved doing a search on "Enumeration
>> > enum" and then refactor "enum" to "enums". There's also an Itereation
>> > called "enum", so don't forget to search for that.
>> >
>> > Once you did these two bits, Cocoon 2.1.5 will compile perfectly and
>> be
>> > very fast. I ran through the major samples and they all came up
>> > perfectly and very fast.
>> >
>> > Hope this helps somebody.
>> >
>> > Now, is the "enum" problem going to be solved with Cocoon 2.1.6?
>> >
>> >
>> > Bert
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> > For additional commands, e-mail: users-help@cocoon.apache.org
>> >
>> >
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon and JDK 1.5
Posted by Bert Van Kets <co...@vankets.com>.
Your remarks are correct. I do read the dev list too.
It still forces people to get the CVS version of commons-lang and in the
2.1 Branch certainly not all uses of the "enum" variable are replaced.
There are still 19 cases of the "enum" declaration.
Bert
On Tue, 2004-10-26 at 21:34, Ralph Goers wrote:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109710228801931&w=2
> and
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109691665429634&w=2
>
> Bert Van Kets said:
> > This "rant" is about Cocoon 2.1.5
> >
> > The biggest problem using JDK 1.5 is the use of "enum" in the source
> > code. This variable or object name is not allowed any more as enum is a
> > new type of variable in JDK 1.5.
> > There are however still quite a lot of uses of "enum" in the Cocoon
> > source.
> >
> > First I rebuilt Jakarta Common Lang to solve the package problem in the
> > forms and Woody block. "enum" is part of the package and has been
> > replaced with "enums". The current commons-lang-2.0.jar file still
> > contains the old package name. I needed to get the CVS version from the
> > commons project and create the new jar using the "enums" package. If
> > people are interested I can set this on a public location.
> >
> > The next problem to tackle is the use of "enum" in many packages. When
> > you use Eclipse, this is easily solved doing a search on "Enumeration
> > enum" and then refactor "enum" to "enums". There's also an Itereation
> > called "enum", so don't forget to search for that.
> >
> > Once you did these two bits, Cocoon 2.1.5 will compile perfectly and be
> > very fast. I ran through the major samples and they all came up
> > perfectly and very fast.
> >
> > Hope this helps somebody.
> >
> > Now, is the "enum" problem going to be solved with Cocoon 2.1.6?
> >
> >
> > Bert
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> > For additional commands, e-mail: users-help@cocoon.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Cocoon and JDK 1.5
Posted by Bert Van Kets <co...@vankets.com>.
This "rant" is about Cocoon 2.1.5
The biggest problem using JDK 1.5 is the use of "enum" in the source
code. This variable or object name is not allowed any more as enum is a
new type of variable in JDK 1.5.
There are however still quite a lot of uses of "enum" in the Cocoon
source.
First I rebuilt Jakarta Common Lang to solve the package problem in the
forms and Woody block. "enum" is part of the package and has been
replaced with "enums". The current commons-lang-2.0.jar file still
contains the old package name. I needed to get the CVS version from the
commons project and create the new jar using the "enums" package. If
people are interested I can set this on a public location.
The next problem to tackle is the use of "enum" in many packages. When
you use Eclipse, this is easily solved doing a search on "Enumeration
enum" and then refactor "enum" to "enums". There's also an Itereation
called "enum", so don't forget to search for that.
Once you did these two bits, Cocoon 2.1.5 will compile perfectly and be
very fast. I ran through the major samples and they all came up
perfectly and very fast.
Hope this helps somebody.
Now, is the "enum" problem going to be solved with Cocoon 2.1.6?
Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org