Return-Path: Delivered-To: apmail-jakarta-jetspeed-dev-archive@www.apache.org Received: (qmail 54523 invoked from network); 25 Jan 2005 02:12:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 25 Jan 2005 02:12:45 -0000 Received: (qmail 56588 invoked by uid 500); 25 Jan 2005 02:12:42 -0000 Delivered-To: apmail-jakarta-jetspeed-dev-archive@jakarta.apache.org Received: (qmail 56563 invoked by uid 500); 25 Jan 2005 02:12:42 -0000 Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jetspeed Developers List" Reply-To: "Jetspeed Developers List" Delivered-To: mailing list jetspeed-dev@jakarta.apache.org Received: (qmail 56549 invoked by uid 99); 25 Jan 2005 02:12:41 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from postoffice.finali.com (HELO fincorpms1.finali.com) (66.179.180.201) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 24 Jan 2005 18:12:41 -0800 Received: by postoffice.finali.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Jan 2005 19:11:11 -0700 Received: from finali.com (rwatler.finali.com [172.16.9.145]) by fincorpms1.finali.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id C6HCNLT7; Mon, 24 Jan 2005 19:10:56 -0700 From: Randy Watler To: Jetspeed Developers List Message-ID: <41F5AB0A.6090207@finali.com> Date: Mon, 24 Jan 2005 19:12:26 -0700 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [J2] page update from layout portlets implementation question References: <41F02500.8090508@douma.nu> <41F0313E.6020601@finali.com> In-Reply-To: <41F0313E.6020601@finali.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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