>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 3/7/06, James Reynolds wrote: > > > > > > >There is a subtle but important issue. Container managed security > > only > > >operates on the original URL to which a GET or POST was directed ... it > > does > > >*not* apply to RequestDispatcher.forward() calls. In JSF terms, that > > means you can protect the form submit, >but it is up to the application > > to decide whether or not navigation to a particular page is allowed. > > > > > >The RFE being discussed here could do something like a custom > > navigation handler with a pluggable strategy for >choosing whether or > > not navigation (according to the navigation rules) is actually going to > > be permitted or >not. One implementation of this strategy could be > > based on user roles, but you could also do something more >fine grained > > or context sensitive (since the strategy implementation would have > > access to FacesContext, it can >do whatever it needs). > > > > > >Craig > > > > > > I think I understand: if I use an action method to forward a user to a > > different page based on its String name in my Faces-Config.xml, I'm > > basically employing RequestDispatcher.forward(), which circumvents the > > container managed security. Did I get it? > > > Yep. As Gary points out, you could make your navigation rules use redirects > and the constraints would still be applied, but you'd have to deal with > passing state information yourself. > > In theory, couldn't I set a role property for each page in its > > element and then conditionally render the page, or > > redirect elsewhere, based on my user's role stored in session? > > > The DTD for a managed-bean entry is fixed, and doesn't include a place for > this information. It will need to be configured elsewhere. But I'm not > sure that the managed bean entry would be the correct place anyway ... > although it is typical to have a backing bean per view, this is not > required. >
True. I forgot about the case where your action contains the literal outcome and not a EL binding. <commandButton action="viewSalary" value="next"/> I see now why the navigation handler is the right place. > If so, should this evaluation take place in the init() method of every > > page's bean, or is there a better way to handle it globally? > > > My thinking was that this sort of thing could be provided either as a custom > NavigationHandler that consulted extra information before allowing the > standard navigation rule to be applied, and/or made a service object > available that could be consulted by your application action (and would also > be used by the custom NavigationHandler). This sort of thing would let you > use a rules engine, or compose custom logic, that the framework would ask > "is it ok to go from here to there, for this particular user, at this > particular time?". > I like the idea of making a service and then you could use it for the visibility of widgets in a "rendered" binding beside "forward" navigation. Almost seems like a job for common chains? Gary > Thanks > > > Craig >
