[jira] Created: (JS2-236) PageManager Folder/Page security needs to support multiple page.security files
PageManager Folder/Page security needs to support multiple page.security files -- Key: JS2-236 URL: http://issues.apache.org/jira/browse/JS2-236 Project: Jetspeed 2 Type: Improvement Components: PSML Versions: 2.0-M3 Reporter: Randy Watler Assigned to: Randy Watler Priority: Minor Fix For: 2.0-M3 PageManager Page/Folder constraints security implementation, (bronco), does not support multiple page.security files as documented. At a minimum, subsites need to support their own page.security files. Generalizing the implementation to support page.security definitions embedded within the site hierarchy should be considered... probably with a strict replacement aggregation policy within the hierarchy to limit performance overhead. The current implementation restricts the location of the page.security file to the site root folder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JS2-235) Cleanup PageManager to enforce Page/Folder security symmetrically
Cleanup PageManager to enforce Page/Folder security symmetrically - Key: JS2-235 URL: http://issues.apache.org/jira/browse/JS2-235 Project: Jetspeed 2 Type: Task Versions: 2.0-M3 Reporter: Randy Watler Assigned to: Randy Watler Priority: Minor Fix For: 2.0-M3 PageManager and related implementations do not enforce Page/Folder security constraints/permissions consistantly across all APIs. PageManager.getFolder() and PageManager.newPage() probably need to restrict VIEW and EDIT access assuming an end user is attempting to perform these operations as part of a site management/customization process. Will need to review site admin portlets to ensure that tightened APIs do not hinder operation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59846 ] Randy Watler commented on JS2-69: - Team, After devoting some time to this issue over the week I think I have come up with the heart of a proposal. I plan on commiting it to an official design document in all of its glory soon, but I would like some feedback first. Here is the general scheme: 1. An inital request comes in for a authenticated user immediately after login on some request url, (usually the portal root). Since this is the first request in a new session for the end user, the PageManager, Profiler, and new PortalNavigations component initializes a new context object that is attached to the session. This object will hold all cached profiled site information for the session to maximize reuse/scaling and hold sufficient state information about the user, pages, and active profiling rules to allow it to compute profiled site portal navigations dynamically later in the execution of the request pipeline. 2. The "site" session context object is initialized/reset with only these elements when the ProfilerValve is invoked in the pipeline: the root folder, the current page, and a creation timestamp. All Folder, Page, and other document instances managed within the site session context object will be proxies that are arranged into a standard hirarchical site definition with the aid of the PageManager and Profiler. Unlike the current implementation, all elements managed by the site session context can be navigated to locate relative profiled site content, (i.e. getParent(), getSiblingFolders(), getFolders(), etc. will reflect the profiled site). These proxies will delegate all access and operations to the underlying objects managed by the PageManager, except those that maintain the proxy hierarchy. As mentioned, the initial site session context object will be sparsely populated. As the end user navigates through the portal and the Page Layout Templates are constructed, the site session context object will cache more of the profiled site definition by constructing the proxy hierarchy dynamically. The cached proxy hierarchy will be cleared when the session is destroyed or the PageManager cache is cleared due to a change in the physical PSML content. 3. Basic utilities will be implemented by the site session context object that mimic the existing PageManager/Profiler features. These will minimally include: getPage(), getFolder(), getSiblingFolders(), getSiblingPages(), and getRootLinks(). The new getRootFolder(), getRootPages(), and getRootFolders() access will also implemented to facilitate ad-hoc access to the root of the profiled site. 4. Document sets will be deprecated and replaced with named menu definitions that will appear in the folder.metadata files. In the broadest terms, these new folder based menu definitions will be a super set of the existing document set features. In addition to the ability to define and profile multiple menu definitions using alternate profiling rules and regular expression path sets, new capabilities based on explicit XML menu tags to define ragged nested menus inline will be implemented. Also, common menu design patterns/idioms can be easily specified using the declarative XML menu tags, (e.g. it would be trivial to define a simple XML definition to specify a menu tree composed of all root level folders and their pages). Individually named menu definitions will be inherited, (in a strictly non-aggregating style), down the profiled PSML hierarchy as one would expect so that they can be overriden in lower levels in the site. When accessed by the Page Layout Templates, the site session context object will construct and cache each named menu definition using another hierarchy of proxied Folder, Page and other document instances. This proxy hierarchy can be easily navigated by the Page Layout Templates to generate many simple or cascading Portal Navigation styles. 5. The implementation of the functionality behind the site session context object and its proxy hierarchies will be encapsulated in a separate component I am referring to as the PortalNavigations component. I am also considering the implementation of another compatible component that simply returns underlying Folders, Pages, and other documents from the PageManager without employing the Profiler or Security; this would also eliminate the need for proxies and delegation. Given the flexibilty of the intended APIs outlined above, I am not sure there is a need to micro componentize the full function PortalNavigations functionality. By only computing exactly what a Page Layout Template requests and employing session based caching, it is not clear that any performance advantage would be realized by further decomposition. However, I am still considering the implementation of individual menu definition idioms as components. 6. At the moment, I am
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59483 ]
Randy Watler commented on JS2-69:
-
After reviewing Ate's proposal and comments from 7/3/2004,
(http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=15857), and
factoring in recent discussions on the topic, it seems that there is the
beginning of a consensus around providing a profiled view of folders and pages
from the root to a specified depth. This top level "site map" could be used to
drive global portal navigations that supplement or replace the existing page
relative navigation elements.
Generally, the goal is to provide some basic information "out of the box",
(i.e. w/o the need for document sets or other configuration information), to
support typical navigations for small to medium sized portals.
Support for profiling is a must, so simply returning a reference to the
underlying physical view of the portal content is not acceptable. However, a
hierarchical object representation of the "site map" that contains profiled
folders and documents is probably required to allow nested menu representations
including javascript dhtml pulldown renderings to be constructed easily.
The desired "depth" of the root level "site map" would probably need to be
somewhat variable to support ragged pulldown menu trees. Consequently, it seems
that some form of a menu definition will be required, minimally some kind of
path set specification like: "{/*,/*/,/deep0/*,/deep1/*,/deeper/*/}". Of
course, a simple default like "{/*,/*/*}" would due in many cases. If paths are
too limiting, a full XML menu definition might be required... but there have
been other votes against such a thing.
This "site map" would probably be specified globally, or possibly at the
individual folder level. If folder level specification is required, it should
support some form of inheritance so that navigations specified in the root or
parent folders would serve as the default folder menu definition.
Given that the profiler would be used to generate this "site map", it does not
seem that any capability to specify multiple menu definitions per user, group,
role, mediatype, etc. would be needed or desirable. Instead, the contents of a
single "site map" would be determined by profiler folder aggregation and
security filtering. If folder level specification is implemented, the specific
folder and menu definition could also be selected by the profiler as a by
product of selecting the portal page to be displayed.
Caching of these portal "site maps" can be significantly easier than reusing
the existing navigational elements generated today. In fact, if folder level
specification is not supported and a single global menu definition is allowed,
the resulting "site map" can be generated once and cached per session. This
advantage should be carefully considered when making the decision to support
folder level specification.
> Finallizing Portal Navigation using the Profiler
>
>
> Key: JS2-69
> URL: http://issues.apache.org/jira/browse/JS2-69
> Project: Jetspeed 2
> Type: New Feature
> Components: Profiling/Portal Navigation
> Versions: 2.0-dev/cvs, 2.0-a1
> Reporter: Scott T Weaver
> Assignee: Randy Watler
> Priority: Critical
>
> We still haven't settled on how we are going to generate navigations in J2.
> I have some modifications to the Profiler and to the theme logic which may
> give us some direction. I am bringing this up as I have been privellage to
> quite a few vendor portal demos lately allowing me to see both the good and
> the bad of multiple implementations.
> - I would say we replace the getDesktop() with getFolders(). There is really
> no need for a "root" item or Folder per se since we will be leaving this job
> to the current set of profilling rules that have been assigned to the
> Profiler.
> - Folders will contain any number of pages and/or folders.
> - Folder items would be ordered the following way: first by assigned index
> then by alphabetical order.
> - Remove defaultPage logic from Folder, the focused Folder item would be set
> in this fashion: set the focus to the last selected child in that Folder then
> by Folder Item ordering algothrim defined above.
> - It should be the Profiler's responsibility to preserve a user's active item
> on a per Folder basis.
> - A Folder would still posses the defaultTheme capabillity but with the added
> abillity to enforce the defaultTheme on its childern and its childrens'
> children by overriding the theme settings for those items with its own.
> - Rendering the contents of the Profiler.getFolders() would be left entirely
> up to the theme (currently called the layout decorator). Example: a theme
> could render the first 2 levels as tabs and the rest as a hierarchical menu
> to the left of the layout area.
> - DO NOT in
[jira] Commented: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=comments#action_59481 ] Randy Watler commented on JS2-69: - >From "Ate Douma" <[EMAIL PROTECTED]> Subject Re: Declarative or Modal Page Layout Navigation? Date Sun, February 20, 2005 1:57 pm To "Jetspeed Developers List" Randy Watler wrote: > Team, > > David and I have been discussing potential options to the current > profiler/page-manager generated page layout navigations. While what we > have seems to be fairly powerful and flexible, it also seems to be too > complex and/or scalable for use by many users. It often raises questions > on the lists and certainly does not seem self documenting! Fully agreed! > > We have discussed implementing a declarative navigation definition, > (i.e. J1 menus), that could be specified globally or at the folder > level. We have also pondered some modal configuration settings/hints to > the existing solution that correspond to different navigational styles, > (i.e. relative forward/back navigation as we currently have, constant > navigation elements that reflect the physical folder structures, logical > view specifications like document sets, etc.). Obviously, changes to > support these different modes would also involve modifications to the > various velocity layout templates. Related efforts might include support > for javascript pull down menus or other portal navigation interfaces. +1 ;-) One of my own outstanding requirements I haven't found time yet to find a solution for. We've been here before and several solutions have been suggested in the past (including one of my own). Lets try to get this right once and for all! > Finallizing Portal Navigation using the Profiler > > > Key: JS2-69 > URL: http://issues.apache.org/jira/browse/JS2-69 > Project: Jetspeed 2 > Type: New Feature > Components: Profiling/Portal Navigation > Versions: 2.0-dev/cvs, 2.0-a1 > Reporter: Scott T Weaver > Assignee: Randy Watler > Priority: Critical > > We still haven't settled on how we are going to generate navigations in J2. > I have some modifications to the Profiler and to the theme logic which may > give us some direction. I am bringing this up as I have been privellage to > quite a few vendor portal demos lately allowing me to see both the good and > the bad of multiple implementations. > - I would say we replace the getDesktop() with getFolders(). There is really > no need for a "root" item or Folder per se since we will be leaving this job > to the current set of profilling rules that have been assigned to the > Profiler. > - Folders will contain any number of pages and/or folders. > - Folder items would be ordered the following way: first by assigned index > then by alphabetical order. > - Remove defaultPage logic from Folder, the focused Folder item would be set > in this fashion: set the focus to the last selected child in that Folder then > by Folder Item ordering algothrim defined above. > - It should be the Profiler's responsibility to preserve a user's active item > on a per Folder basis. > - A Folder would still posses the defaultTheme capabillity but with the added > abillity to enforce the defaultTheme on its childern and its childrens' > children by overriding the theme settings for those items with its own. > - Rendering the contents of the Profiler.getFolders() would be left entirely > up to the theme (currently called the layout decorator). Example: a theme > could render the first 2 levels as tabs and the rest as a hierarchical menu > to the left of the layout area. > - DO NOT introduce the idea of controls and controllers. It has been stated > before that these easily confuse people and I agree 100%. We need to keep > things simple. > I think the first profiling/navgation implementation would be assigning n > number of roles to a top-level folder. Then allow the Profiler to aggregate > what Folders a user has access to by comparing the roles that user is > assigned to the ones required the Folders required roles (ACL?) I think this > approach is already somewhat in place but it just needs some final > implementation details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JS2-215) security email extensions: password reminder/user creation
security email extensions: password reminder/user creation -- Key: JS2-215 URL: http://issues.apache.org/jira/browse/JS2-215 Project: Jetspeed 2 Type: Improvement Components: Security Versions: 2.0-M1 Reporter: Randy Watler Fix For: 2.0-M2 >From "Ate Douma" <[EMAIL PROTECTED]> Subject Re: More Login/Security Enhancements Date Sun, February 20, 2005 1:44 pm To "Jetspeed Developers List" Randy Watler wrote: > Ate/All, > > I have these additional Login/Security requirements that have made there > way into a formal requirements process for our portal implementation: > > - Send email to end user for forgotten passwords, (offered on failed > login attempts if user email address known). +1 > - Ability of a non-authenticated end user to create and populate a > disabled user account to be enabled later by admin/moderator, (includes > automatic email notification of the request and approved/denied messages > if user email address known). +1 > > I think these features are fairly typical for most sites requiring end > user authentication. Is there any interest in, (or objections to), these > features being added to J2 proper? If there is interest, I will generate > a JIRA issue and we can see if there are other similar capabilities that > can be added at the same time. +1 I myself have been asked by my client to provide more/correct feedback to a user trying to login but whose account already has been disabled (too many failed login attempts). The current functionality clearly isn't giving good feedback at all. The problem to do this better though is that there isn't a formal way to communicate information back *through* the JAAS implementation (i.e. the Tomcat JAASRealm) to the client (J2). We need to provide our own channel or such for that. > > Thanks! > > Randy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (JS2-69) Finallizing Portal Navigation using the Profiler
[ http://issues.apache.org/jira/browse/JS2-69?page=history ] Randy Watler reassigned JS2-69: --- Assign To: Randy Watler > Finallizing Portal Navigation using the Profiler > > > Key: JS2-69 > URL: http://issues.apache.org/jira/browse/JS2-69 > Project: Jetspeed 2 > Type: New Feature > Components: Profiling/Portal Navigation > Versions: 2.0-dev/cvs, 2.0-a1 > Reporter: Scott T Weaver > Assignee: Randy Watler > Priority: Critical > > We still haven't settled on how we are going to generate navigations in J2. > I have some modifications to the Profiler and to the theme logic which may > give us some direction. I am bringing this up as I have been privellage to > quite a few vendor portal demos lately allowing me to see both the good and > the bad of multiple implementations. > - I would say we replace the getDesktop() with getFolders(). There is really > no need for a "root" item or Folder per se since we will be leaving this job > to the current set of profilling rules that have been assigned to the > Profiler. > - Folders will contain any number of pages and/or folders. > - Folder items would be ordered the following way: first by assigned index > then by alphabetical order. > - Remove defaultPage logic from Folder, the focused Folder item would be set > in this fashion: set the focus to the last selected child in that Folder then > by Folder Item ordering algothrim defined above. > - It should be the Profiler's responsibility to preserve a user's active item > on a per Folder basis. > - A Folder would still posses the defaultTheme capabillity but with the added > abillity to enforce the defaultTheme on its childern and its childrens' > children by overriding the theme settings for those items with its own. > - Rendering the contents of the Profiler.getFolders() would be left entirely > up to the theme (currently called the layout decorator). Example: a theme > could render the first 2 levels as tabs and the rest as a hierarchical menu > to the left of the layout area. > - DO NOT introduce the idea of controls and controllers. It has been stated > before that these easily confuse people and I agree 100%. We need to keep > things simple. > I think the first profiling/navgation implementation would be assigning n > number of roles to a top-level folder. Then allow the Profiler to aggregate > what Folders a user has access to by comparing the roles that user is > assigned to the ones required the Folders required roles (ACL?) I think this > approach is already somewhat in place but it just needs some final > implementation details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
