I am porting a sample blog application to JSF to get a better feel for the API.
Two features of the application require the user to be logged-in prior to using. The use case is pretty straight forward. 1- All of the application options are displayed at all times as links. 2- Only logged in users can access protected features (e.g. replying to an existing blog entry and creating a new thread). 3- If an anonymous user attempts to access a protected feature they should be redirected to the login page. 4- Once they successfully login they should be redirected to the feature they attempted to access in step 2. This doesn't seem to be a good fit for the "enabledOnUserRole" attribute that the myfaces X components have. Since I want the link enabled, but the requests "routing" to be altered. In a request based web application I would ordinarily write a servlet filter. If it caught a request to a secure resource, it would: - check for the user object in session - if the user object didn't exist, it would save the requested url and the query string as a request param. - forward the request to the login page. - the login page would save the original request as a hidden field - after a successful login, the controller would redirect the user to the URL originally requested passing along the query params This solution was predicated on two facts: - The secured resources were always accessed via distinct http GETs. So a user requesting a reply to an existing blog always took the form of http://myURL/reply.do?blogEntryId=123. An unsecured controller would never simply include the contents of a secured resources (e.g. a reply) in its own response. - All request state was contained between the URL and query string. Granted, this solution is limiting, it satisfies the use case I normally face. Please note that this used custom security - there was no use of the JAAS, J2EE security etc. When I went trolling around for suggestions on an appropriate solution in JSF, I kept running across variations of a specialized Navigation Handler. The custom navigation handler is very similar to the one found at http://www.jsftutorials.net/jsfNavigation/jsf-login-navigation-redirect.html . A sample action method: public String replyToThisBlogEntry() { //get the data row selected from the DataModel object Entry replyTo = findActiveEntry(); //pass the entry that the user is replying to, //to the reply pages backing object ReplyHandler replyHandler = findReplyHandler(); replyHandler.setReplyTo(replyTo); return "reply"; } My problem with the custom NavigationHandler solution is that the original resource requested, in this case "reply", requires a certain amount of state above and beyond the original handleNavigation() arguments - fromAction, outcome and viewId. In this case, the ReplyHandler must have a reference to the correct Entry object. Other action methods may even more elaborate implementations. Should I attempt to copy over the request scope attributes (which should include the effected managed beans) when forwarding to the login view, and then restore these request scope attributes when forwarding to the secure resource? That seems a bit convoluted - and a bit dependent on how the underlying jsf implementation stores the request scope attributes. Am I going about this the wrong way - trying to fit a request framework peg in an event framework hole? Should I handle the security in the action method itself and then store the entry object (or any other applicable request state) in the login handler? This seems a bit cumbersome and would require special handling for each secure feature added. Any suggestions? TIA for any help! Carlos
