Bug 35985 - [Patch] AC live: can't restrict access to a document in live area
Summary: [Patch] AC live: can't restrict access to a document in live area
Alias: None
Product: Lenya
Classification: Unclassified
Component: Access Control (show other bugs)
Version: Trunk
Hardware: Other other
: P2 normal
Target Milestone: 1.4
Assignee: Lenya Developers
Depends on:
Reported: 2005-08-02 22:53 UTC by Doug Chestnut
Modified: 2005-08-25 09:12 UTC (History)
0 users

use closest ancestor-or-self policy (1.44 KB, patch)
2005-08-02 22:54 UTC, Doug Chestnut
Details | Diff
use closest ancestor-or-self policy take 2 (1.54 KB, patch)
2005-08-04 23:40 UTC, Doug Chestnut
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Doug Chestnut 2005-08-02 22:53:01 UTC
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.
Comment 1 Doug Chestnut 2005-08-02 22:54:21 UTC
Created attachment 15858 [details]
use closest ancestor-or-self policy
Comment 2 solprovider 2005-08-03 08:27:53 UTC
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]

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

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
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.
Comment 3 Doug Chestnut 2005-08-04 23:40:11 UTC
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.
Comment 4 Doug Chestnut 2005-08-25 17:12:51 UTC
applied patch