Remember, the RequestProcessor is a 1.1 thing. You'll have to be using the nightly build for it. Of course, the beta is just around the corner. Anyway, the Struts 1.1 DTD defines a new element called "controller". It goes under the root element after the action-mappings. Make sure that it's in the correct location. It should be the last element in your struts config, unless you have plug-in's defined. Here's an example of one from my book:
<controller contentType="text/html;charset=UTF-8" debug="3" locale="true" nocache="true" processorClass="com.oreilly.struts.framework.CustomRequestProcessor" /> Notice that many of the things that were configured in the web.xml in 1.0 are now attributes on this element. The CustomerRequestProcessor listed here extends the Struts version and this is where I override the mehtod. You don't have to do anything with the ActionServlet. In fact, since the RequestProcessor is where all of the meat is now, you can just use the Struts ActionServlet as is and there's usually no need to subclass it. Chuck Cavaness -----Original Message----- From: Matt Read [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 1:22 PM To: [EMAIL PROTECTED] Subject: RE: validate() and session expiry Yes, but probably a little too ambitious for me I think. On a related note though, I can't work out what to do with your subclassed RequestProcessor class once you've overridden the processPreprocess() method? Any pointers on the where you configure this to be used? Do you also have to subclass the ActionServlet and set the processor field in your subclass to the new RequestProcessor? Thanks, Matt. -----Original Message----- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: 05 March 2002 16:16 To: 'Struts Users Mailing List' Subject: RE: validate() and session expiry You could always extend ActionMapping (or ActionConfig for 1.1) to accept more parameter type attributes. Of course at that point, you're extending the framework but's that neccessarily a bad thing. Chuck -----Original Message----- From: Matt Read [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 11:04 AM To: [EMAIL PROTECTED] Subject: RE: validate() and session expiry That looks good too but given that you're only allowed to have one <parameter> per action mapping it would preclude the use of parameter for anything else. It would definitely make DispatchAction difficult to use. I do like the idea of being able to configure this in struts-config.xml though. Maybe it could be implemented as requiresSession="true"? Matt. -----Original Message----- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: 05 March 2002 12:57 To: Struts Users Mailing List Subject: RE: validate() and session expiry Matt, I had one other idea that I wanted to share with you. It came to be as I was just starting to work on the security chapter for the Struts book. This is for the case where you have a small number of actions that the user needs to be logged in for, rather than all of them. What if you added a value like "checkSession" using the parameter attribute in the action mappings that required the user to be logged in. In the "processPreprocess" method, you can look up the mapping for the action that has been requested using ActionMapping mapping = findMapping(path); which is available in the ActionServlet class as well. Once you have the mapping, yoy can call "getParameter", which will return a String for the parameter in the ActionMapping. If no value is specified, a null is returned. If "checkSession" of some other value is present, then you know to check to see if the session is present and valid. If so, return true, which allows the ActionServlet to continue on. Otherwise, you can use the ActionMapping that you already found for the action and return to the login page. You are probably better off declaring a global forward and using the findForward(String name) method in the ActionServlet to locate the global login forward and forward to this. By doing it like this, you make the whole thing very generic and declarative. You are free to change which actions need to have the user logged in without modifying any source code. The "processPreprocess" method stays completly generic. What does everything about this approach? I think I'll mention this in the security chapter of the book. Chuck At 12:14 PM 3/5/2002 +0000, you wrote: >Yep, all makes sense. Thanks to both of you. I'm a lot happier with how the >logic is partitioned now and I like the validate="false" idea very much. > >Thanks, >Matt. > >-----Original Message----- >From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] >Sent: 05 March 2002 03:01 >To: Struts Users Mailing List >Subject: RE: validate() and session expiry > > >Your problem is slightly different than ours. In our application, the user >had to be logged in to go anywhere. This mechanism was a way to catch the >problem when a user has already logged in and let's the session timeout. >They then invoke an action that has a form that uses the session object for >something, like getting the user's Locale. Although I agree with Bryan that >having anything other than presentation validation in the ActionForm is >dangerous, let's face it; sometimes we do stupid things. > >Chuck > >At 02:50 AM 3/5/2002 +0000, you wrote: > >Thanks, that sounds like a good solution. My only reservation is that in > >processPreprocess() you'd have to effectively hard-code a list of the > >request paths that require a user to login. I suppose you have to do it > >somewhere though. > > > >Matt. > > > >-----Original Message----- > >From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] > >Sent: 05 March 2002 02:34 > >To: Struts Users Mailing List > >Subject: Re: validate() and session expiry > > > > > >We had the same issue to deal with. What we did was in our ActionServet > >(which subclassed Struts ActionServlet), was to override the > >"processPreprocess" method, which is called for every request. We checked > >the session there, instead of in every Action perform method. If the > >session is expired or the user isn't logged in, we perform a redirect to > >the login page. This worked out very nicely and also allowed us to remove > >the check in the Action classes, since this method is called before the > >ActionForm validate and the Action perform method. > > > >In 1.1, this method is moved to the RequestProcessor class, but it works > >the same way. I'm sure there are other solutions, but this is one approach. > > > >Chuck Cavaness > > > >At 02:20 AM 3/5/2002 +0000, you wrote: > > >I've got a problem and I'm not sure whether it's my poor design or a >struts > > >limitation. I'd appreciate it if someone can shed some light. Let me know > >if > > >you require more details. > > > > > >I have an action mapping for an "update my profile" page with an >associated > > >ActionForm and validate="true". In order to navigate to this form the >user > > >has to login first. The Action itself checks that the user is logged in >in > > >the perform() method. If he isn't then he's forwarded back to the login > > >action. This all works fine in the case where the session expires and the > > >user clicks on the link to take him to the form because he gets forwarded > >to > > >the login page. > > > > > >My problem is that if he navigates to this form, then waits for the >session > > >to timeout then clicks submit then the validate() method on the >ActionForm > > >is called BEFORE the perform() method on the Action itself. In my case >the > > >validation fails as it relies on being able to read data from the >session. > > > > > >I can see a solution where in validation() methods I check that the >session > > >is still valid but this seems clumsy to me. Is it good MVC design for the > > >request to be handled by the Model before the Controller gets to see it? >Am > > >I incorrectly putting business logic into the validation() method when it > > >should be dealt with further down the chain? Or should I be handling my > > >authentication and session management in a subclass of the ActionServlet? > > > > > >I'd appreciate any insights. > > >Matt. > > > > > > > > >-- > > >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]> > > > >-- >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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
