> > > > Aside: if I return a list of comma separated roles could the > > > > portal still be > > > > made to work? > > > > > > > Yes, it should still work. > > > > The portal knows enough to tokenize the role string? > > > Rethinking about this, it's a little bit difficult. > The portal uses the role name to build the profile, which means > a profile for the role is used in this process. > So the portal needs one role to build the profile.
Right. Sounds like it's a 'profile selector', not a true role (e.g. not a group, or set of permissions, etc). I can also understand the need for a simplification where each user gets only one profile but couldn't one do something where the user's profile is the union of all profiles from all their roles? > > > > - I'm not clear why the SessionContextImpl doesn't implement > > some of the > > > > functions like getNodeList(String path). > > > > > > > Reason is simple: Lazy developer. Send a patch :) > > > > > > It's not inherent in the fact that the 'sunRise' context spans the > > authentication, request, response and application XML? There's no > > problem in > > your mind with returning NodeLists from across them? > > > Hmm, no - the Nodes itself have to be copied before, so the application > can not accidentally change the nodes. Ah, interesting, I had actually noticed that they were 'live' and was thinking of using that fact. Clearly a no-no :-) You mean: nodes have to be cloned to be returned in the list. > > If not, I just might send that patch ;-) > > Great! Time permitting ;-) > > > > Thoughts for doing multiple roles: > > > > > > > > + comma separated list of roles inside <role> (yes, sounds > > flaky doesn't > > > > it). > > > > > > > It's not a nice solution, but should work. > > > > And you mentioned above that the portal will accept comma > delimited roles > > within <role> already (e.g. it isn't doing an equals() but some kind of > > tokenization? > > > Ok, it will not work. > > > > > + add to the <data> section > > > > > > > Yes, this is the solution others use (afaik). > > > > Really? Others have done this? Anyone posted anything? > > I know customers of us which did this. Ah. > > > > Aside: what contexts (besides 'sunRise') is the > > SessionContextImpl used > > > > instead of SimpleSessionContext? > > > > > > > What do you mean? Why the SessionContextImpl is used instead of the > > > SimpleSessionContext? > > > > Well, that is the question really. But I'm also curious if I use > > <sunshine:getxml> when I'm hitting SimpleSessionContext and when > > I'm hitting > > SessionContextImpl. > > > In fact, you don't have to distinguish - it makes no difference > when using the context. Sure, I understood that, the reason I'm asking is to determine whether or not I need to do the NodeList work discussed above. E.g. if I don't need anything from context ABC and XYZ and those are the only two that use SessionContextImpl (which doesn't return NodeLists) then I may not bother doing the work discussed above. > One note about multiple roles: > > The authentication framework was designed with the idea that a user > has only one role at a time. She is either admin, user or guest - but > not all at the same time. Of course a user can have different roles > over time. > But a login specifies exactly one role for the duration of the session. > > If you look at a portal for example, this makes sense. You have a portal > configuration for an admin and one for a usual user. At some point > of time you have to decide what portal to display for the user - you > can't display both or somehow combine them. > > So the "authentication/role" information should be seen as > "current role" - it does not cover the possible roles the user could > also have. > > If someone has a good idea on how to combine these efforts, let's do it. I think the portal's needs are a separate question from correctly implementing roles so that SunRise is actually a complete login/authentication package. If multiple roles aren't possible, for example, I'll have to use container managed security to get multiple roles and then I won't have all the great session and config management stuff you did. I think that both needs can be met by: - extending roles to allow multiple roles (either through comma separated list of roles in current <authentication> schema or through a different schema [e.g. <roles><role>...</role></roles>]) - extending the <authentication> schema to identify which role determines the profile to use in the portal. E.g. <authentication><profile>foobar</profile>...</authentication> That should be a separate concern of just the portal code. - lastly, integrating with container managed security would be a real nice to have. Comments? Per --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
