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 Aaron Evans <aa...@yahoo.ca> on 2005/11/22 19:24:56 UTC
J2 - Portlet Filter Equivalent
Hey guys,
I see that in the Portlet spec that a future requirement is to support the
notion of a Portlet Filter. It is too bad it isn't there at the moment as
it would be really nice.
So, I'm looking for suggestions for something that will more or less
accomplish the same thing. That is, some piece of logic will be invoked
prior to invoking the processAction or the render methods of portlets.
There are a number of things I would like to accomplish in this phase:
1. perform role-based security checks against the invoked portlet.
This would require that:
-I would know which portlet is being invoked.
-I would have access to the PortletRequest object (and thus the portlet
context as well).
-I would need to somehow render some kind of access denied fragment if
the security check didn't pass.
2. check the user principal name and if there is a "Profile" session object
and load the matching profile object if it is missing or if there is a
mismatch and bind it to the session.
This would require that:
-I would have access to the PortletRequest object (and thus the portlet
application session).
I realize for the latter, that there are user attributes and so forth for
the "profile" requirements. However, I am utilizing tomcat's SSO functionality
and will need a comprehensive profile in servlet apps outside of the portal
anyway. This also gives me the ability to store more than just strings.
I don't think there is anything that can accomplish the above really so
I think I will proceed with creating a Portlet interface and base Portlet
class that will implement this functionality in its render and processAction
methods that all of my other portlets will need to extend/implement.
This of course does not help me with existing 3rd party portlets, especially
J2 admin portlets.
However, I would like to see if anyone else has any suggestions. Perhaps
a valve of somekind?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: J2 - Portlet Filter Equivalent
Posted by James Liao <ji...@gmail.com>.
Take a look at this: http://issues.apache.org/jira/browse/PB-15
- James Liao
On 11/23/05, Patrick Huber <st...@gmail.com> wrote:
>
> aop (aspect oriented programming) - it's kind of an additional
> dimension to programming where you 'weave' your aspects into your
> existing code.
> so for example you'd define a piece of code which is to be executed
> before each execution of Portlet.processAction. The Portlet doesn't
> know its processAction is being wrapped by an aspect.So in your case,
> all security code is in the Aspect and the Portlets are free of any
> security code.
>
> Since jetspeed uses the spring framework already, I'd propose you'd go
> with spring's aop implementation, which is based on the AOP Alliance
> implementation (docs:
> http://static.springframework.org/spring/docs/1.2.x/reference/aop.html).
>
> There are of course other implementations too. One of them is AspectJ.
>
> The main differences betwenn most AOP implementations are wether they
> do runtime oder compiletime weaving of the aspects. And the way you
> define your jointpoints etc. is different too.
>
> 2005/11/22, Aaron Evans <aa...@yahoo.ca>:
> > Patrick Huber <stackmagic <at> gmail.com> writes:
> >
> > >
> > > I think there are several possibilities. I'm not sure if they all work
> > > but I think they should:
> > > - use aop to intercept calls to each portlet's processAction method
> > > - use a servlet filter for the portal (most defenitely no access to
> > > the portlet request, only the httpservlet request from the browser)
> > > - use a servlet filter for the portlet (probable access to the portlet
> > > request, you'd need to test this first)
> > > - use a portlet filter (which would require websphere
> > > http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp
> > ?topic=/com.ibm.wp.ent.doc/wps/adpltflt.html)
> > >
> > > Of all these, I'd prefer the aop variant.
> >
> > Thanks for the reply Patrick. I can solve my session object problem,
> the
> > portlet security problem is the bigger one.
> >
> > WebSphere is out.
> >
> > I don't think servlet filters will work for a couple of reasons. I still
> won't
> > know which portlet is being invoked or if it is among the ones that will
> be
> > rendered, even if I apply a servlet filter on the portal. If I put a
> servlet
> > filter on my portlet app, I'm pretty sure it doesn't get invoked for a
> portlet.
> >
> > This aop sounds promising. What is it and where can I find out more
> about it?
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> > For additional commands, e-mail: jetspeed-user-help@portals.apache.org
> >
> >
>
>
> --
> "I love deadlines. I like the whooshing sound they make as they fly
> by." -- Douglas Adams
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
Re: J2 - Portlet Filter Equivalent
Posted by Patrick Huber <st...@gmail.com>.
aop (aspect oriented programming) - it's kind of an additional
dimension to programming where you 'weave' your aspects into your
existing code.
so for example you'd define a piece of code which is to be executed
before each execution of Portlet.processAction. The Portlet doesn't
know its processAction is being wrapped by an aspect.So in your case,
all security code is in the Aspect and the Portlets are free of any
security code.
Since jetspeed uses the spring framework already, I'd propose you'd go
with spring's aop implementation, which is based on the AOP Alliance
implementation (docs:
http://static.springframework.org/spring/docs/1.2.x/reference/aop.html).
There are of course other implementations too. One of them is AspectJ.
The main differences betwenn most AOP implementations are wether they
do runtime oder compiletime weaving of the aspects. And the way you
define your jointpoints etc. is different too.
2005/11/22, Aaron Evans <aa...@yahoo.ca>:
> Patrick Huber <stackmagic <at> gmail.com> writes:
>
> >
> > I think there are several possibilities. I'm not sure if they all work
> > but I think they should:
> > - use aop to intercept calls to each portlet's processAction method
> > - use a servlet filter for the portal (most defenitely no access to
> > the portlet request, only the httpservlet request from the browser)
> > - use a servlet filter for the portlet (probable access to the portlet
> > request, you'd need to test this first)
> > - use a portlet filter (which would require websphere
> > http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp
> ?topic=/com.ibm.wp.ent.doc/wps/adpltflt.html)
> >
> > Of all these, I'd prefer the aop variant.
>
> Thanks for the reply Patrick. I can solve my session object problem, the
> portlet security problem is the bigger one.
>
> WebSphere is out.
>
> I don't think servlet filters will work for a couple of reasons. I still won't
> know which portlet is being invoked or if it is among the ones that will be
> rendered, even if I apply a servlet filter on the portal. If I put a servlet
> filter on my portlet app, I'm pretty sure it doesn't get invoked for a portlet.
>
> This aop sounds promising. What is it and where can I find out more about it?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
--
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: J2 - Portlet Filter Equivalent
Posted by Aaron Evans <aa...@yahoo.ca>.
Patrick Huber <stackmagic <at> gmail.com> writes:
>
> I think there are several possibilities. I'm not sure if they all work
> but I think they should:
> - use aop to intercept calls to each portlet's processAction method
> - use a servlet filter for the portal (most defenitely no access to
> the portlet request, only the httpservlet request from the browser)
> - use a servlet filter for the portlet (probable access to the portlet
> request, you'd need to test this first)
> - use a portlet filter (which would require websphere
> http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp
?topic=/com.ibm.wp.ent.doc/wps/adpltflt.html)
>
> Of all these, I'd prefer the aop variant.
Thanks for the reply Patrick. I can solve my session object problem, the
portlet security problem is the bigger one.
WebSphere is out.
I don't think servlet filters will work for a couple of reasons. I still won't
know which portlet is being invoked or if it is among the ones that will be
rendered, even if I apply a servlet filter on the portal. If I put a servlet
filter on my portlet app, I'm pretty sure it doesn't get invoked for a portlet.
This aop sounds promising. What is it and where can I find out more about it?
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: J2 - Portlet Filter Equivalent
Posted by Patrick Huber <st...@gmail.com>.
I think there are several possibilities. I'm not sure if they all work
but I think they should:
- use aop to intercept calls to each portlet's processAction method
- use a servlet filter for the portal (most defenitely no access to
the portlet request, only the httpservlet request from the browser)
- use a servlet filter for the portlet (probable access to the portlet
request, you'd need to test this first)
- use a portlet filter (which would require websphere
http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.ibm.wp.ent.doc/wps/adpltflt.html)
Of all these, I'd prefer the aop variant.
2005/11/22, Aaron Evans <aa...@yahoo.ca>:
> Hey guys,
> I see that in the Portlet spec that a future requirement is to support the
> notion of a Portlet Filter. It is too bad it isn't there at the moment as
> it would be really nice.
>
> So, I'm looking for suggestions for something that will more or less
> accomplish the same thing. That is, some piece of logic will be invoked
> prior to invoking the processAction or the render methods of portlets.
>
> There are a number of things I would like to accomplish in this phase:
>
> 1. perform role-based security checks against the invoked portlet.
> This would require that:
> -I would know which portlet is being invoked.
> -I would have access to the PortletRequest object (and thus the portlet
> context as well).
> -I would need to somehow render some kind of access denied fragment if
> the security check didn't pass.
>
> 2. check the user principal name and if there is a "Profile" session object
> and load the matching profile object if it is missing or if there is a
> mismatch and bind it to the session.
> This would require that:
> -I would have access to the PortletRequest object (and thus the portlet
> application session).
>
> I realize for the latter, that there are user attributes and so forth for
> the "profile" requirements. However, I am utilizing tomcat's SSO functionality
> and will need a comprehensive profile in servlet apps outside of the portal
> anyway. This also gives me the ability to store more than just strings.
>
> I don't think there is anything that can accomplish the above really so
> I think I will proceed with creating a Portlet interface and base Portlet
> class that will implement this functionality in its render and processAction
> methods that all of my other portlets will need to extend/implement.
>
> This of course does not help me with existing 3rd party portlets, especially
> J2 admin portlets.
>
> However, I would like to see if anyone else has any suggestions. Perhaps
> a valve of somekind?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>
--
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org