There appears to be no way (cms gui) to restrict access to a section of the live area of a site. The InheritingPolicyManager (FilePolicyManager) steps through the request url and adds up all the policies (inclusive). This works out great for the authoring area, but is fairly useless for the live area (as far as I understand). This patch to FilePolicyManager just uses the first ancestor-or-self policy for the requested document (instead of all the policies belonging to the document and it's ancestor nodes) when the request is for a live document.
Created attachment 15858 [details] use closest ancestor-or-self policy
This is a compilation of my posts about security to the MLs. They started with a complaint that Lenya's specifications are not being met. This line is from Lenya's homepage: "The access control allows you to restrict access to parts of your site to members of a group or individuals." That line was there when I downloaded Lenya 1.2.2, and is still there today. I did much work to make it true for my project, including rewriting how Search results are generated. The default pub grants access to "world" for the homepage, and all other pages inherit that access, so "restricting access to parts of your site" is difficult. My project handles security in XSL, but XSL should be for formatting, not functionality. My workaround has an "awareness" security flaw: an unauthorized page returns different results than a nonexistent page. The message in both cases should be: "The page requested could not be found, or you are not allowed to access it. You may need to login." This could be handled in a Sitemap with something like auth-protect, but that is where application functionality is defined; a Usecase sitemap should not bypass the security because the author forgot to copy some code. I think it needs to be built into the File Generator. That might be a Virtual Component (if they exist), but hardcoding into the Java would be best. On 6/24/05, Andreas Hartmann <andreas@apache.org> wrote: Maybe it could even be added in the repository layer, or at least in the RepositorySource (lenya:// protocol). Then it wouldn't be restricted to generation, but it would also apply to all other operations on a document. [END Andreas' input] Great! 1. The protocol gets request for a file. 2. Checks if document exists. 3. Checks if security exists for file. 4. Checks if security passes for file. 5. Checks if language exists. - language-version-does-not-exist flag: (document-level, but falls up path to publication flag) E = Standard error D = Fallback to default language (Standard error if it does not exist.) C = Show language choice page (nolang.xml explained below.) 6. If any check fails, return publication error message. If publication does not have error message, use global error message. If this is implemented, we can remove these from the Pipelines: - language-exists Action - document-does-not-exist Exception because it would be impossible to create them. Sitemaps become slightly simpler; productivity increases (less code!) Where is the security config? In every document? In sitetree.xml? Or in a new file? Where are the error messages? An errors directory under config or content? - error.xml (Standard Error for NotFound, NoLanguageVersion, and NotAuthorized) - anonerr.xml (Standard Error suggesting login, fallback to error.xml) - nolang.xml ("<i18n>The requested document is available for these languages</i18n>: de, us, xx.") [Referring to search results using my Search which has been integrated with Lenya1.2.4.] Security should read from a configuration file. It is easy to add reading a file to search-and-results.xsp, but that configuration file should also be used for preventing protected pages from displaying, and removing items from the menus.
Created attachment 15893 [details] use closest ancestor-or-self policy take 2 With this mod to FilePolicyManager you can use the AC Live tab to restrict access to a page or group of pages in the live area. I had to clean a few things up from the first patch.
applied patch