You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Santiago Gala <sg...@hisitech.com> on 2003/03/03 17:10:52 UTC
Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets
PortletWrapper.java
taylor@apache.org wrote:
> taylor 2002/09/17 08:44:00
>
> Modified: src/java/org/apache/jetspeed/portal/security/portlets
> PortletWrapper.java
> Log:
> Added method to get around cast firewall.
> Plan to convert this code to properly use Java Proxies.
>
> Revision Changes Path
> 1.13 +7 -2 jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets/PortletWrapper.java
>
> Index: PortletWrapper.java
> ===================================================================
> RCS file: /home/cvs/jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets/PortletWrapper.java,v
> retrieving revision 1.12
> retrieving revision 1.13
> diff -u -r1.12 -r1.13
> --- PortletWrapper.java 3 Sep 2002 15:02:13 -0000 1.12
> +++ PortletWrapper.java 17 Sep 2002 15:44:00 -0000 1.13
> @@ -439,5 +439,10 @@
> public boolean providesCustomization()
> {
> return wrappedPortlet.providesCustomization();
> - }
> + }
> +
> + public Portlet getPortlet()
> + {
> + return wrappedPortlet;
> + }
> }
>
>
I was reviewing the differences between the security code I have hanging
for Jetspeed 1.3b3 and the current one, and I found this commit. It
completely defeats the facade purpose, which is authorization.
If it is really needed, we could as well completely remove these classes
from the system, or at least move them under a different package
"security" is a misnomer.
I introduced these classes with two purposes:
* make clear where the authorization code would be in the system and
ensure that no code out of the core system could fake authorization.
* even more important, have opaque facades for the third party portlets.
This helps cleaning contracts between portlets and the container. It
"enforces the Portlet API". If a method is discovered to be missing from
the scheme, we can add it (both in the base interface and here). So, the
wrappers would act as "barriers" against API pollution.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=jetspeed-dev@jakarta.apache.org&msgId=99099
was one of the last messages before I stopped tracking HEAD. There I
expressed my concerns about using transparent proxies, since they
defeated the authorization feature. I would rather remove the
Interceptor than having it opened, since it gives a faux feeling of
security.
Since the method is called with such a common name, I'm not able to find
where it is being used. Could anybody clarify?
Regards,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets
PortletWrapper.java
Posted by Santiago Gala <sg...@hisitech.com>.
David Sean Taylor wrote:
>
> On Monday, March 3, 2003, at 08:10 AM, Santiago Gala wrote:
>
>> taylor@apache.org wrote:
>>
>>> taylor 2002/09/17 08:44:00
>>> Modified: src/java/org/apache/jetspeed/portal/security/portlets
>>> PortletWrapper.java
>>> Log:
>>> Added method to get around cast firewall.
>>> Plan to convert this code to properly use Java Proxies.
>>> Revision Changes Path
>>> 1.13 +7 -2
>>> jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/
>>> portlets/PortletWrapper.java
>>> Index: PortletWrapper.java
>>> ===================================================================
>>> RCS file:
>>> /home/cvs/jakarta-jetspeed/src/java/org/apache/jetspeed/portal/
>>> security/portlets/PortletWrapper.java,v
>>> retrieving revision 1.12
>>> retrieving revision 1.13
>>> diff -u -r1.12 -r1.13
>>> --- PortletWrapper.java 3 Sep 2002 15:02:13 -0000 1.12
>>> +++ PortletWrapper.java 17 Sep 2002 15:44:00 -0000 1.13
>>> @@ -439,5 +439,10 @@
>>> public boolean providesCustomization()
>>> {
>>> return wrappedPortlet.providesCustomization();
>>> - } + } +
>>> + public Portlet getPortlet()
>>> + {
>>> + return wrappedPortlet;
>>> + } }
>>>
>>
>> I was reviewing the differences between the security code I have
>> hanging for Jetspeed 1.3b3 and the current one, and I found this
>> commit. It completely defeats the facade purpose, which is
>> authorization.
>>
>>
>> If it is really needed, we could as well completely remove these
>> classes from the system, or at least move them under a different
>> package "security" is a misnomer.
>>
> That sounds like an over-reaction.
> Please don't remove the security wrappers. That would break countless
> applications.
> I hope you are speaking out of frustration.
> Rename the package if it makes you happy, I don't care.
>
I was not planning to remove them. Yes, possibly I'm overreacting. No, I
don't think it makes sense to rename the package.
>> I introduced these classes with two purposes:
>> * make clear where the authorization code would be in the system and
>> ensure that no code out of the core system could fake authorization.
>> * even more important, have opaque facades for the third party
>> portlets. This helps cleaning contracts between portlets and the
>> container. It "enforces the Portlet API". If a method is discovered
>> to be missing from the scheme, we can add it (both in the base
>> interface and here). So, the wrappers would act as "barriers" against
>> API pollution.
>
>
> They are not a barrier. You can change the security classes just as
> easily as the API.
Yes, but no "consumer" of the class will be allowed to access public
methods in subclasses by casting. This was heavily abused, and was
spoiling the code more and more. In this sense they have acted as barriers.
> As for the Jetspeed Portlet API, do we even want to bother discussing
> it at this point?
>
Not tha API itself, but I would like to have Jetspeed code base ready
for migration (and understand dependencies) for when the API is released
and discussions begin.
That also is motivating my "clean unused imports" campaign ;-)
>> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=jetspeed-
>> dev@jakarta.apache.org&msgId=99099
>>
>> was one of the last messages before I stopped tracking HEAD. There I
>> expressed my concerns about using transparent proxies, since they
>> defeated the authorization feature. I would rather remove the
>> Interceptor than having it opened, since it gives a faux feeling of
>> security.
>>
> You can't just remove the security feature from Jetspeed.
> Paul and I worked very hard on putting in declarative security into
> Jetspeed, and decoupling Jetspeed security from Turbine. Programmers
I know you worked very hard into this. I will not remove anything. Sorry
if I sounded like I would.
> have complete access to the security API, the full source code. In
> short they can do whatever they please. Once Jetspeed has a clean
> separation between container and portal engine, these issues will
> become more important.
>
>> Since the method is called with such a common name, I'm not able to
>> find where it is being used. Could anybody clarify?
>
>
> In reviewing the commits, I can't find the cast problem I was having.
> It must have been in some client code.
> I know it was very important, or I wouldn't have committed it.
>
> My vote is remove the method, and I will have to leave it in for my
> project.
> It will make extra work for me, but Im used to that when working with
> Jetspeed.
> I don't have to worry about third party portlet programmers breaking
> into security in my applications.
>
I will try to remove it in my copy, and see if something breaks. After
this, I will warn and commit the change.
Regards,
Santiago
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets PortletWrapper.java
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Monday, March 3, 2003, at 08:10 AM, Santiago Gala wrote:
> taylor@apache.org wrote:
>> taylor 2002/09/17 08:44:00
>> Modified: src/java/org/apache/jetspeed/portal/security/portlets
>> PortletWrapper.java
>> Log:
>> Added method to get around cast firewall.
>> Plan to convert this code to properly use Java Proxies.
>> Revision Changes Path
>> 1.13 +7 -2
>> jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/
>> portlets/PortletWrapper.java
>> Index: PortletWrapper.java
>> ===================================================================
>> RCS file:
>> /home/cvs/jakarta-jetspeed/src/java/org/apache/jetspeed/portal/
>> security/portlets/PortletWrapper.java,v
>> retrieving revision 1.12
>> retrieving revision 1.13
>> diff -u -r1.12 -r1.13
>> --- PortletWrapper.java 3 Sep 2002 15:02:13 -0000 1.12
>> +++ PortletWrapper.java 17 Sep 2002 15:44:00 -0000 1.13
>> @@ -439,5 +439,10 @@
>> public boolean providesCustomization()
>> {
>> return wrappedPortlet.providesCustomization();
>> - } + } +
>> + public Portlet getPortlet()
>> + {
>> + return wrappedPortlet;
>> + } }
>>
>
> I was reviewing the differences between the security code I have
> hanging for Jetspeed 1.3b3 and the current one, and I found this
> commit. It completely defeats the facade purpose, which is
> authorization.
>
>
> If it is really needed, we could as well completely remove these
> classes from the system, or at least move them under a different
> package "security" is a misnomer.
>
That sounds like an over-reaction.
Please don't remove the security wrappers. That would break countless
applications.
I hope you are speaking out of frustration.
Rename the package if it makes you happy, I don't care.
> I introduced these classes with two purposes:
> * make clear where the authorization code would be in the system and
> ensure that no code out of the core system could fake authorization.
> * even more important, have opaque facades for the third party
> portlets. This helps cleaning contracts between portlets and the
> container. It "enforces the Portlet API". If a method is discovered to
> be missing from the scheme, we can add it (both in the base interface
> and here). So, the wrappers would act as "barriers" against API
> pollution.
They are not a barrier. You can change the security classes just as
easily as the API.
As for the Jetspeed Portlet API, do we even want to bother discussing
it at this point?
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=jetspeed-
> dev@jakarta.apache.org&msgId=99099
>
> was one of the last messages before I stopped tracking HEAD. There I
> expressed my concerns about using transparent proxies, since they
> defeated the authorization feature. I would rather remove the
> Interceptor than having it opened, since it gives a faux feeling of
> security.
>
You can't just remove the security feature from Jetspeed.
Paul and I worked very hard on putting in declarative security into
Jetspeed, and decoupling Jetspeed security from Turbine. Programmers
have complete access to the security API, the full source code. In
short they can do whatever they please. Once Jetspeed has a clean
separation between container and portal engine, these issues will
become more important.
> Since the method is called with such a common name, I'm not able to
> find where it is being used. Could anybody clarify?
In reviewing the commits, I can't find the cast problem I was having.
It must have been in some client code.
I know it was very important, or I wouldn't have committed it.
My vote is remove the method, and I will have to leave it in for my
project.
It will make extra work for me, but Im used to that when working with
Jetspeed.
I don't have to worry about third party portlet programmers breaking
into security in my applications.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org