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 Mark Dimon <ma...@dimon.freeserve.co.uk> on 2001/10/16 08:06:42 UTC

AbstractPortletControl Bug ???

Hi,

I've noticed that in

 org.apache.jetspeed.portal.controls.AbstractPortletControl

the methods *like* allowClose()  do the security check with a || rather than
an && , if I change this to && then the permissions behave as
expected  and you can now disable the close icon's ect for users with the
admin pane.

Is this a bug ? or something unfinished ?

---------------------------------------------------------------------------

   public boolean allowClose( RunData rundata )
    {
        Portlet p = getPortlet();

        if (p==null) return false;

        if ((p instanceof PortletSet)
            /*** this should be && not || ??? ***/  ||
(JetspeedSecurity.checkPermission(rundata,

JetspeedSecurity.PERMISSION_CLOSE,
                                                p)))
        {
            if (p instanceof PortletState)
            {
                return ((PortletState)p).allowClose(rundata);
            }
        }

        return false;
    }

----------------------------------------------------------------------------
-



Regards Mark


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


Re: AbstractPortletControl Bug ???

Posted by Santiago Gala <sg...@hisitech.com>.
Mark Dimon wrote:

>I found another related problem , with 'entry' being null in
>checkPermisson() in jetspeedDBSecurityService and not caught now that that
>the function is being executed due to the &&. + I got problems after making
>that change .. not sure if related , will do some more checking tommorow
>
Yes. I took the security conscious approach (no entry, no permission). 
Maybe someone can check why entry is null sometimes...

I think the patch you sent was not really needed. The problem is with 
AbstractPortlet.allowXXX(), which is not making the security checks. I'm 
currently testing this. I'll report on this one.

>
>
>Regards Mark.
>
>----- Original Message -----
>From: "Santiago Gala" <sg...@hisitech.com>
>To: <je...@jakarta.apache.org>
>Sent: Tuesday, October 16, 2001 11:22 AM
>Subject: Re: AbstractPortletControl Bug ???
>
>
>>Mark Dimon wrote:
>>
>>>Hi,
>>>
>>>I've noticed that in
>>>
>>>org.apache.jetspeed.portal.controls.AbstractPortletControl
>>>
>>>the methods *like* allowClose()  do the security check with a || rather
>>>
>than
>
>>>an && , if I change this to && then the permissions behave as
>>>expected  and you can now disable the close icon's ect for users with the
>>>admin pane.
>>>
>>>Is this a bug ? or something unfinished ?
>>>
>>It *was* a bug :-)
>>
>>Thanks a lot. I was trying to find just now why this feature was not
>>working. I'll patch this in a few hours.
>>
>>>
>>---------------------------------------------------------------------------
>>
>>>  public boolean allowClose( RunData rundata )
>>>   {
>>>       Portlet p = getPortlet();
>>>
>>>       if (p==null) return false;
>>>
>>>       if ((p instanceof PortletSet)
>>>           /*** this should be && not || ??? ***/  ||
>>>(JetspeedSecurity.checkPermission(rundata,
>>>
>>>JetspeedSecurity.PERMISSION_CLOSE,
>>>                                               p)))
>>>       {
>>>           if (p instanceof PortletState)
>>>           {
>>>               return ((PortletState)p).allowClose(rundata);
>>>           }
>>>       }
>>>
>>>       return false;
>>>   }
>>>
>>---------------------------------------------------------------------------
>>
>-
>
>>>-
>>>
>>>
>>>
>>>Regards Mark
>>>
>>>
>>>---------------------------------------------------------------------
>>>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
>>
>>
>
>
>---------------------------------------------------------------------
>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: AbstractPortletControl Bug ???

Posted by Mark Dimon <ma...@dimon.freeserve.co.uk>.
I found another related problem , with 'entry' being null in
checkPermisson() in jetspeedDBSecurityService and not caught now that that
the function is being executed due to the &&. + I got problems after making
that change .. not sure if related , will do some more checking tommorow


Regards Mark.

----- Original Message -----
From: "Santiago Gala" <sg...@hisitech.com>
To: <je...@jakarta.apache.org>
Sent: Tuesday, October 16, 2001 11:22 AM
Subject: Re: AbstractPortletControl Bug ???


> Mark Dimon wrote:
>
> >Hi,
> >
> >I've noticed that in
> >
> > org.apache.jetspeed.portal.controls.AbstractPortletControl
> >
> >the methods *like* allowClose()  do the security check with a || rather
than
> >an && , if I change this to && then the permissions behave as
> >expected  and you can now disable the close icon's ect for users with the
> >admin pane.
> >
> >Is this a bug ? or something unfinished ?
> >
>
> It *was* a bug :-)
>
> Thanks a lot. I was trying to find just now why this feature was not
> working. I'll patch this in a few hours.
>
> >
> >
>
>---------------------------------------------------------------------------
> >
> >   public boolean allowClose( RunData rundata )
> >    {
> >        Portlet p = getPortlet();
> >
> >        if (p==null) return false;
> >
> >        if ((p instanceof PortletSet)
> >            /*** this should be && not || ??? ***/  ||
> >(JetspeedSecurity.checkPermission(rundata,
> >
> >JetspeedSecurity.PERMISSION_CLOSE,
> >                                                p)))
> >        {
> >            if (p instanceof PortletState)
> >            {
> >                return ((PortletState)p).allowClose(rundata);
> >            }
> >        }
> >
> >        return false;
> >    }
> >
>
>---------------------------------------------------------------------------
-
> >-
> >
> >
> >
> >Regards Mark
> >
> >
> >---------------------------------------------------------------------
> >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
>
>


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


Re: AbstractPortletControl Bug ???

Posted by Santiago Gala <sg...@hisitech.com>.
Mark Dimon wrote:

>Hi,
>
>I've noticed that in
>
> org.apache.jetspeed.portal.controls.AbstractPortletControl
>
>the methods *like* allowClose()  do the security check with a || rather than
>an && , if I change this to && then the permissions behave as
>expected  and you can now disable the close icon's ect for users with the
>admin pane.
>
>Is this a bug ? or something unfinished ?
>

It *was* a bug :-)

Thanks a lot. I was trying to find just now why this feature was not 
working. I'll patch this in a few hours.

>
>
>---------------------------------------------------------------------------
>
>   public boolean allowClose( RunData rundata )
>    {
>        Portlet p = getPortlet();
>
>        if (p==null) return false;
>
>        if ((p instanceof PortletSet)
>            /*** this should be && not || ??? ***/  ||
>(JetspeedSecurity.checkPermission(rundata,
>
>JetspeedSecurity.PERMISSION_CLOSE,
>                                                p)))
>        {
>            if (p instanceof PortletState)
>            {
>                return ((PortletState)p).allowClose(rundata);
>            }
>        }
>
>        return false;
>    }
>
>----------------------------------------------------------------------------
>-
>
>
>
>Regards Mark
>
>
>---------------------------------------------------------------------
>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: Response Time in Netscape 4.7xx ?

Posted by Santiago Gala <sg...@hisitech.com>.
Norman Schöneich wrote:

>Hi,
>
>The cvs jetspeed site and my website based on jetspeed are very slow in
>loading the pages under Netscape 4.7xx.
>
The problem is related with the implementation of table rendering in 
Netscape 4.0

>
>Internet Explorer and Netscape 6.x are rendering the site in a sufficient
>manner. What's the problem ?
>Have other users the same problem ?
>Maybe it's a problem of nestings tables, i don't know !
>
Yes, it is. The only way to make rendering faster is to minimize the 
maximum depth of table nesting for each PSML page.

If you are interested in checking this, you could try to write templates 
for Netscape 4 that load faster, and use the Profiler to select them 
when the user agent is Netscape 4.

>
>
>
>Best regards
>
>norsch
>
>Norman Schöneich
>
>
>---------------------------------------------------------------------
>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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Re: Response Time in Netscape 4.7xx ?

Posted by Paul Spencer <pa...@mikon.com>.
Norman,
Jetspeed uses a lot of nested tables.  Netscape 4.7 is known to have
performance problems with nested tables.  Depending on the complexity if
the Portal, some of the tables can be remove by editing the navigation,
template, and layout files.

Please do not cross post.  Post messages to ONE list!

Paul Spencer

Norman Schöneich wrote:
> 
> Hi,
> 
> The cvs jetspeed site and my website based on jetspeed are very slow in
> loading the pages under Netscape 4.7xx.
> Internet Explorer and Netscape 6.x are rendering the site in a sufficient
> manner. What's the problem ?
> Have other users the same problem ?
> Maybe it's a problem of nestings tables, i don't know !
> 
> Best regards
> 
> norsch
> 
> Norman Schöneich
> 
> ---------------------------------------------------------------------
> 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-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org


Response Time in Netscape 4.7xx ?

Posted by Norman Schöneich <sc...@ecooperate.de>.
Hi,

The cvs jetspeed site and my website based on jetspeed are very slow in
loading the pages under Netscape 4.7xx.
Internet Explorer and Netscape 6.x are rendering the site in a sufficient
manner. What's the problem ?
Have other users the same problem ?
Maybe it's a problem of nestings tables, i don't know !


Best regards

norsch

Norman Schöneich


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


Response Time in Netscape 4.7xx ?

Posted by Norman Schöneich <sc...@ecooperate.de>.
Hi,

The cvs jetspeed site and my website based on jetspeed are very slow in
loading the pages under Netscape 4.7xx.
Internet Explorer and Netscape 6.x are rendering the site in a sufficient
manner. What's the problem ?
Have other users the same problem ?
Maybe it's a problem of nestings tables, i don't know !


Best regards

norsch

Norman Schöneich


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