You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Hema Menon <me...@gmail.com> on 2004/12/11 00:25:16 UTC

Session information for a Struts portlet in JS1.6

Hi,

How can a struts application deployed as a JSR 168 portlet in Jetspeed
1.6 with fusion get the user information and other session variables
in Jetspeed's context? In other words we have some jetspeed 1.5 which
are running under jetspeed 1.6 with fusion. We converted an existing
struts application to be deployed as a portlet in Jetspeed. We have
authentication done thru sybase and when the user logs in user
information and some other relevant information are added to the
session. These variables are available to all the portlets in
jetspeed. However when a struts portlet is added to jetspeed, the
context seems to be different even though it resides in the jetspeed
portal. The question is
1. Is it possible for the struts application to access the session
variables that are added on login?
2. If it is how can it be done?

Any inputs very much appreciated.

Thanks,
Hema




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hema Menon

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Re: Session information for a Struts portlet in JS1.6

Posted by Ate Douma <at...@douma.nu>.

Jeff Sheets wrote:
> I just want to clarify one point of your post.
> 
> You're saying that all of the portlets in one war file, thus a part of
> the same application, share the same session.  But it's not true that
> each "portlet" has it's own session, just each portlet application
> [war], right?
Correct.

> 
> At least that's how I understood it, but I just wanted to get some
> clarification from the experts :-)
> 
> -- Jeff Sheets
> 
> 
> On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma <at...@douma.nu> wrote:
> 
>>
>>
>>
>>Hema Menon wrote:
>>
>>>Hi,
>>>
>>>How can a struts application deployed as a JSR 168 portlet in Jetspeed
>>>1.6 with fusion get the user information and other session variables
>>>in Jetspeed's context? In other words we have some jetspeed 1.5 which
>>>are running under jetspeed 1.6 with fusion. We converted an existing
>>>struts application to be deployed as a portlet in Jetspeed. We have
>>>authentication done thru sybase and when the user logs in user
>>>information and some other relevant information are added to the
>>>session. These variables are available to all the portlets in
>>>jetspeed. However when a struts portlet is added to jetspeed, the
>>>context seems to be different even though it resides in the jetspeed
>>>portal. The question is
>>>1. Is it possible for the struts application to access the session
>>>variables that are added on login?
>>
>>Yes :-)
>>
>>
>>>2. If it is how can it be done?
>>
>>There are several factors at play here.
>>First of all, cross-context restrictions. In contrast to other (non-JSR168)
>>portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
>>web applications and accesses them using the cross-context feature of Tomcat.
>>According to the servlet specs, each web application *must* have its own
>>session, so formally, access to cross-context session is not supported.
>>But, there are two solutions to this problem I know of (if you find more I'd
>>would like to know about it).
>>
>>1) Use Tomcat 4
>>Tomcat 4 has the annoying bug in that it does *not* create separate sessions
>>for cross-context access. Normally, this is quite a security breach and one of
>>the reasons why I'm never going to use Tomcat 4 again.
>>But, it might be helpful in your situation. Then, you should have direct access
>>to your login variables.
>>
>>2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
>>That returns a RequestContext instance which gives you access to the session of the
>>portal (getSessionAttribute() and setSessionAttribute()).
>>
>>Note: while the RequestContext is defined in the public (J2) jetspeed-api package,
>>the Jetspeed class is *not*. So, you will have to build against the J2 portal.
>>Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
>>team) might conclude that this is too much of a security breach and close that
>>backdoor in the future. But, in that case I expect us to at least leave read-only
>>access in place as we rely on it ourselves for the J2 management portlets.
>>
>>Good luck, Ate
>>
>>
>>
>>
>>>Any inputs very much appreciated.
>>>
>>>Thanks,
>>>Hema
>>>
>>>
>>>
>>>
>>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>Hema Menon
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Re: Session information for a Struts portlet in JS1.6

Posted by Jeff Sheets <je...@gmail.com>.
I just want to clarify one point of your post.

You're saying that all of the portlets in one war file, thus a part of
the same application, share the same session.  But it's not true that
each "portlet" has it's own session, just each portlet application
[war], right?

At least that's how I understood it, but I just wanted to get some
clarification from the experts :-)

-- Jeff Sheets


On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma <at...@douma.nu> wrote:
> 
> 
> 
> 
> Hema Menon wrote:
> > Hi,
> >
> > How can a struts application deployed as a JSR 168 portlet in Jetspeed
> > 1.6 with fusion get the user information and other session variables
> > in Jetspeed's context? In other words we have some jetspeed 1.5 which
> > are running under jetspeed 1.6 with fusion. We converted an existing
> > struts application to be deployed as a portlet in Jetspeed. We have
> > authentication done thru sybase and when the user logs in user
> > information and some other relevant information are added to the
> > session. These variables are available to all the portlets in
> > jetspeed. However when a struts portlet is added to jetspeed, the
> > context seems to be different even though it resides in the jetspeed
> > portal. The question is
> > 1. Is it possible for the struts application to access the session
> > variables that are added on login?
> Yes :-)
> 
> > 2. If it is how can it be done?
> There are several factors at play here.
> First of all, cross-context restrictions. In contrast to other (non-JSR168)
> portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
> web applications and accesses them using the cross-context feature of Tomcat.
> According to the servlet specs, each web application *must* have its own
> session, so formally, access to cross-context session is not supported.
> But, there are two solutions to this problem I know of (if you find more I'd
> would like to know about it).
> 
> 1) Use Tomcat 4
> Tomcat 4 has the annoying bug in that it does *not* create separate sessions
> for cross-context access. Normally, this is quite a security breach and one of
> the reasons why I'm never going to use Tomcat 4 again.
> But, it might be helpful in your situation. Then, you should have direct access
> to your login variables.
> 
> 2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
> That returns a RequestContext instance which gives you access to the session of the
> portal (getSessionAttribute() and setSessionAttribute()).
> 
> Note: while the RequestContext is defined in the public (J2) jetspeed-api package,
> the Jetspeed class is *not*. So, you will have to build against the J2 portal.
> Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
> team) might conclude that this is too much of a security breach and close that
> backdoor in the future. But, in that case I expect us to at least leave read-only
> access in place as we rely on it ourselves for the J2 management portlets.
> 
> Good luck, Ate
> 
> 
> 
> >
> > Any inputs very much appreciated.
> >
> > Thanks,
> > Hema
> >
> >
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Hema Menon
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> >
> >
> >
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Re: Session information for a Struts portlet in JS1.6

Posted by Hema Menon <me...@gmail.com>.
Hi Ate,

Thanks a lot for your prompt response. Tomcat 4 is a definite 'no' for
us. We are currently on 5.0.28 and is likely to switch to 5.5. So I
guess I'll have to look into the option of using
getCurrentRequestContext(). I'll try it out with our application, and
may have more followup questions on it. Again, thanks for the
information.

Hema

On Sat, 11 Dec 2004 10:13:17 +0100, Ate Douma <at...@douma.nu> wrote:
> 
> 
> 
> 
> Hema Menon wrote:
> > 1. Is it possible for the struts application to access the session
> > variables that are added on login?
> Yes :-)
> 
> > 2. If it is how can it be done?
> There are several factors at play here.
> First of all, cross-context restrictions. In contrast to other (non-JSR168)
> portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
> web applications and accesses them using the cross-context feature of Tomcat.
> According to the servlet specs, each web application *must* have its own
> session, so formally, access to cross-context session is not supported.
> But, there are two solutions to this problem I know of (if you find more I'd
> would like to know about it).
> 
> 1) Use Tomcat 4
> Tomcat 4 has the annoying bug in that it does *not* create separate sessions
> for cross-context access. Normally, this is quite a security breach and one of
> the reasons why I'm never going to use Tomcat 4 again.
> But, it might be helpful in your situation. Then, you should have direct access
> to your login variables.
> 
> 2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
> That returns a RequestContext instance which gives you access to the session of the
> portal (getSessionAttribute() and setSessionAttribute()).
> 
> Note: while the RequestContext is defined in the public (J2) jetspeed-api package,
> the Jetspeed class is *not*. So, you will have to build against the J2 portal.
> Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
> team) might conclude that this is too much of a security breach and close that
> backdoor in the future. But, in that case I expect us to at least leave read-only
> access in place as we rely on it ourselves for the J2 management portlets.
> 
> Good luck, Ate

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hema Menon

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Re: Session information for a Struts portlet in JS1.6

Posted by Ate Douma <at...@douma.nu>.

Hema Menon wrote:
> Hi,
> 
> How can a struts application deployed as a JSR 168 portlet in Jetspeed
> 1.6 with fusion get the user information and other session variables
> in Jetspeed's context? In other words we have some jetspeed 1.5 which
> are running under jetspeed 1.6 with fusion. We converted an existing
> struts application to be deployed as a portlet in Jetspeed. We have
> authentication done thru sybase and when the user logs in user
> information and some other relevant information are added to the
> session. These variables are available to all the portlets in
> jetspeed. However when a struts portlet is added to jetspeed, the
> context seems to be different even though it resides in the jetspeed
> portal. The question is
> 1. Is it possible for the struts application to access the session
> variables that are added on login?
Yes :-)

> 2. If it is how can it be done?
There are several factors at play here.
First of all, cross-context restrictions. In contrast to other (non-JSR168)
portlets, Jetspeed-2 (fusion) deploys its portlet applications as separate
web applications and accesses them using the cross-context feature of Tomcat.
According to the servlet specs, each web application *must* have its own
session, so formally, access to cross-context session is not supported.
But, there are two solutions to this problem I know of (if you find more I'd
would like to know about it).

1) Use Tomcat 4
Tomcat 4 has the annoying bug in that it does *not* create separate sessions
for cross-context access. Normally, this is quite a security breach and one of
the reasons why I'm never going to use Tomcat 4 again.
But, it might be helpful in your situation. Then, you should have direct access
to your login variables.

2) Make use of (J2) org.apache.jetspeed.Jetspeed.getCurrentRequestContext().
That returns a RequestContext instance which gives you access to the session of the
portal (getSessionAttribute() and setSessionAttribute()).

Note: while the RequestContext is defined in the public (J2) jetspeed-api package,
the Jetspeed class is *not*. So, you will have to build against the J2 portal.
Furthermore, this is not (yet) a formal supported feature of Jetspeed-2: we (the
team) might conclude that this is too much of a security breach and close that
backdoor in the future. But, in that case I expect us to at least leave read-only
access in place as we rely on it ourselves for the J2 management portlets.

Good luck, Ate

> 
> Any inputs very much appreciated.
> 
> Thanks,
> Hema
> 
> 
> 
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hema Menon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org