portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <rwat...@finali.com>
Subject Re: [J2] page update from layout portlets implementation question
Date Tue, 25 Jan 2005 02:12:26 GMT
Team,

I have simply protected the calls into the PageManager from the 
MultiColumnPortlet to prevent it from disrupting the generation of the 
page in a SecurityException. I think it is necessary to leave the 
updates in place to save the results of running the Customizer. Of 
course, if you do not have edit permission to the underlying page, you 
should never be given the Customization option/buttons. I am still 
testing this solution out, but it has been committed. Please let me know 
if you see any fatal page generation failures. Instead, you should see 
an informational message in the logs like this:

Unable to update page /default-page.psml layout due to security 
permission/constraint.

Randy

Randy Watler wrote:

> Ate,
>
> Thanks for the reply. Inline clarifications below.
>
> Randy
>
> Ate Douma wrote:
>
>> Randy Watler wrote:
>>
>>> Team,
>>>
>>> Ate found a situation where page security implemented in the 
>>> PageManager
>>> is causing a permitted page view to fail.
>>>
>>> As some of you know the page layout portlet attempts to update the page
>>> if it has had to adjust rows and columns while laying out the 
>>> fragments.
>>> This request is made via the PageManager, (David was not aware this was
>>> being done, so perhaps someone can recall why this is being done at 
>>> all)?
>>>
>>> If the user does not have edit permission when the layout update is
>>> requested, I was simply going to silently skip the persistent
>>> update, leaving the trasient edits in place. The problem with this is
>>> that if a page owner comes back in later, the previous update will not
>>> need to be done and thus the page update would not be done as intended
>>> either.
>>>
>>> I could:
>>>
>>> - let the layout portlet simply skip the update,
>>
>>
>> Not sure what the consequences are. Really depends on *why* the 
>> updates are done.
>> I don't know for sure.
>
>
> Others will have to comment, but the layout edit really does take 
> place... it is
> just not being stored persistently.
>
>>
>>> - try to perfrom the update as admin by changing the login for the 
>>> duration
>>> of the update,
>>
>>
>> That might still fail if even the admin doesn't have edit privs 
>> (strange maybe,
>> but true in my usecase) 
>
>
> Yes, but then it just degenerates to the first case, (silently skips 
> the update).
>
>>
>>> - add some kind of dirty flag to the page, or
>>
>>
>> And then what? 
>
>
> Actually perform the update when/if a privleged user uses the page. In 
> otherwords,
> keep trying the update from the layout portlets if the transient 
> "dirty" flag is set and
> clear the flag if it succeeds.
>
>>
>>> - add an API to PageManager that allowed the usual security checks 
>>> to be
>>> skipped.
>>
>>
>> Looks like a backdoor construction to me. And know that the 
>> LayoutPortlets
>> probably won't be running under the jetspeed context in the near 
>> future (the
>> issue about allowing jetspeed to run under a different context). Than 
>> such
>> a solution would really need to open up the security.
>
>
> I think this is why David is asking why this is being done at all... :).
>
>>
>>>
>>> Thoughts?
>>
>>
>> Sorry for not giving any real positive answer :-)
>>
>> Ate
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message