JiRong, I wrote a Filter to mimic container-managed security (with some help from this list) named 'securityfilter' that has a very simple realm interface and can be deployed inside a web app with no realm setup on the server. The config file uses the same syntax as web.xml for the security constraints and form-login stuff. The filter works the same way as container managed security with a few less setup hassles and it eliminates dependence on the server's proprietary realm interface. Security Filter also has an additional feature of allowing you to submit a login request without being forced to the login page (unlike container managed security), which allows you to do things like have a login form on every page.
Security Filter is open source and distributed under an Apache-style license. Container or securityfilter security is nice because it can protect all of your site's resources, the design is time-tested (it is easy to create security holes if you write it yourself), and you can build on the request object's security-related methods. Struts and Tiles tags build on these methods with their role="somerole" attributes, and they are ideal for building programmatic security in your Actions or JSPs. For more information, go here: http://securityfilter.sourceforge.net/ If you don't have real roles to work with, you could create a simple realm implementation where isUserInRole(Principal principal, String role) returns true for some role as long as the principal is not null. Then protect all the URLs that you want people to be logged in to access. The filter or container would then automatically authenticate users by sending them through the login page, and you could use request.getRemoteUser(), etc. to determine who the current user is once they get to your Action and make programmatic security decisions based on that user information. Container or securityfilter based security is not too difficult to use, and it is certainly much easier and more robust than building your own security system. Many people want to do their own login form processing, but I think there are better ways to acheive the goals behind this desire. If you want to put things in the session when the user logs in, you could write a HttpSessionAttributeListener to do the work for you. It would add or remove attributes when the secuirtyfilter adds/changes/removes a user's Principal object in a session (I don't think this would work with container-managed security, however). Another alternative it to create a utility class that you can call to get the attributes. You pass in the request or session, and the utility class would get the attributes from the session or create them, put them in the session, and return them if they weren't already there. Better yet, you could write a filter that would examine each request that comes in (after the securityfilter, if that is what you are using) and create the attributes if the user has been authenticated and they are missing, or delete them if they exist and the user is no longer authenticated. This filter approach would work with both container and securityfilter security, it probably has less overhead than the HttpSessionAttributeListener, and it avoids introducing a new interface for accessing the attributes (which is a disadvantage of the utility class method described above). Note that you need a Servlet 2.3 compliant container to use securityfilter or the filter-based session populator described above. -Max ----- Original Message ----- From: "Struts Newsgroup" <@[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 13, 2002 9:10 PM Subject: What is a better way to check user login? > Subject: What is a better way to check user login? > From: "Hu Ji Rong" <[EMAIL PROTECTED]> > === > Hi, > > I saw various ways to check user login in Struts, but a bit confused. > CheckLogon Tag in Struts example, check user session data, overwrite the > ActionServlet, and so on. Overwrite the ActionServlet maybe also have > problem to migrate to 1.1? > > Can anyone point to a right way? We have normally form based login page to > validate the user. > > Thanks, > JiRong > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
