Pattern A: /unsecured/*
Run whatever unsecured interceptors on these. This would not include the authentication interceptor or the allowed resource check interceptor. That's because these are considered OPEN to everyone. Pattern B: /secured/* Run the authentication check and the resource check interceptors. The authentication check would verify simply that the HttpSession object contains whatever credential token in memory. If this value doesn't exist, you simply don't have any authentication, return LOGIN as your result, sending the user to the login page. The neat thing we did when this happened in our application is we captured the original resource and any parameters, set that value to a page scope variable and stored it in the login form. This way when the user called the LoginAction, we could redirect the user to the original requestsed resource once we got their credentials. The resource check logic for us in my case was simple as well. When we grab the authentication object (User object that is), the object gets populated with a map of resources and their access permissions. This way the data is grabbed only once and gets stored in the session object only during login. Therefore, all resource checks simply verify that the user object contains the resource and desired access. There is no trip to the RDBMS on each web call, reducing the overhead. If a user's access changes during a session, it doesn't get updated. They simply logout and back in and the access is fixed. Lots of ways to do it, but I would keep them separate. Chris > -----Original Message----- > From: Dave Newton [mailto:davelnew...@gmail.com] > Sent: Monday, August 09, 2010 6:23 AM > To: Struts Users Mailing List > Subject: Re: URL authentication > > FWIW, I wouldn't combine the two into the same interceptor since > rather different things... plus resource access is more likely to take > in a different layer, and not be a cross-cutting concern. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
