After letting the existing page/folder security implemention accumulate some
road miles, we have revised its operation slightly to eliminate unexpected
behavior. No changes have been made to the constraint syntax in the *.psml,
folder.metadata, page.security, etc. files. Only these new rules have been
implemented within the PageManager and its pieces parts to deliver a Unix
type file system behavior:
- view permissions are checked on the entity and all folders recursively up
through root.
- edit, (or other), permissions are checked only on the entity.
Only *.link files to absolute urls are exempt from the view permissions
checks, (but still require the recursive folder view checks).
This change also required a slight change to the visibility rules for folder
navigation elements. Instead of simply checking the folder view
permissions, the PageManager now checks to see if there are any accessible
files in the directory according to the active profiler rules. If not, the
folder is filter from the navigational set.
Along with this change, I have also revised the permissions and constraints
on many of the pages and folders in the root directory. By default, most of
the pages require a login with the "user" role. To make any particular page
publicly visible, modify its constraints as follows:
<security-constraints>
<security-constraints-ref>public-view</security-constraints-ref>
</security-constraints>
or
<security-constraints>
<security-constraints-ref>public-edit</security-constraints-ref>
</security-constraints>
or move it to the /Public folder with no constraints.
If you are feeling particularly brave and you did not simply move the page
to the /Public folder, also edit the four
populate-userinfo-for-default-psml.sql variants, copying the entries in
SECURITY_PERMISSION and PRINCIPAL_PERMISSION for '/rss.psml' and rename the
page name accordingly.
Of course, you can just ask me to promote a page to public access and I'll
take care of it when I get an opportunity!
Randy
