Sorry, previous reply was incomplete... > > Follow up questions: > > > > - is there an equivalent call to > HTTPServletRequest.isUserInRole() against > > the authentication context? > > > No (not yet). From java code you can get the content of > "/authentication/role" > and test it against your value. From a pipeline, you have to get the > role using "session:getxml" and then test it in a stylesheet...For such > tests, I always wanted to add a "session:testxml"... > > > - From what I can tell, the SunRise code doesn't support the notion of > > multiple roles per user. It makes the SunRise Authentication > support not a > > complete replacement for container security. Perhaps that > wasn't the goal > > but it's something people will look for. > > > > What's the background for that? Do you think it could be overcome easily > > (how?)? > Yes, there are several solutions, as you pointed out below: > > > > > 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? > > - 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? If not, I just might send that patch ;-) > > 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? > > + add to the <data> section > > > Yes, this is the solution others use (afaik). Really? Others have done this? Anyone posted anything? > > <authentication> > > <ID>per</ID> > > <role>unused</role> > > <data> > > <roles> > > <role>manager</role> > > <role>ibm</role> > > <role>admin</role> > > </roles> > > </data> > > </authentication> > > > > But then I immediately ran into trouble trying to iterate over all the > > nested <role>s inside <roles> since SessionContextImpl doesn't implement > > some of the xpath functions. > > Again, this is only due to a lazy developer - you could implement them. They're already in SimpleSessionContext, I'll copy that code. > > 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. 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]>
