Per Kreipke wrote: > > > 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.
> > > - 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. > If not, I just might send that patch ;-) Great! > > > > 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. > > > > 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. 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. Carsten --------------------------------------------------------------------- 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]>
