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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
