Thanks Danilo for the input. I was thinking about writing a custom filter too. This would work fine to actually prevent a page from being served to the user, but I don't see how I could hide the page from the user as restricting access to the website repository in the ACL will do... That's why I guess that some save handler magic which updates the ACL will maybe have to be applied. Then again: A the save handler for the page properties dialog is configurable. But what about when the editor renames the page in the tree? Maybe observation would be the way to go...
-will On 14.03.2011, at 01:41, Danilo Ghirardelli wrote: > >> We have the request to restrict access to certain pages for certain groups >> (instead of whole branches). Now this of course could be done with the >> regular ACL (editing the roles for every single page which should be >> protected). But this would undoubtedly lead to a configuration nightmare. > > I had a similar problem, but I was "lucky" enough to apply a different > strategy from Magnolia ACLs. My project had spring security, which was > configured as a filter among Magnolia ones, and that filter took care of user > authentication. The "trick" was that all templates have a restricted property > that can be set in the page properties dialog. If this property is true and > the current user has no permission for the page, an exception is thrown. To > be specific, is a spring exception that spring security will catch in its > filter and handle accordingly, redirecting the user to the configured (by > magnolia) login page. > I've seen that the same trick can be easyly extended to check if the template > contains some "special" paragraphs that requires permissions. > > This way, no matter how you change the tree the restricted pages will stay > resticted. Checking for "special" paragraphs will make sure that pages with > restricted content will be automatically restricted. > > I suppose the same trick could be used even without the spring security part, > but you'll have to write a little bit of code that does the same things. > > There is only one downfall (at least for me) for this, and it's the fact that > those security exceptions thrown by templates will be always logged by > rendering filter (or at least the jsp rendering), no matter what, because > currently any exception is logged before rethrow. I opened MAGNOLIA-3595 to > see if there could be a solution for this problem, for now I just filtered > out my exception from logs using the log4j extras, but I don't like this > solution because it's quite heavy. > > Regards, Danilo. > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
