portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/portal/security/portlets PortletWrapper.java
Date Mon, 03 Mar 2003 16:10:52 GMT
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


Mime
View raw message