RE: related to: Re: #2 - Use DispatchAction to organize related operations
Chuck is absolutely correct on the linear progression of action processing. I, too am overriding processPreprocess and it works beautifully. Besides increasing security, it cuts down on unnecessary CPU bandwidth. Mark -Original Message- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 10:58 PM Rick, catch this earlier. I had implemented something along these lines awhile back and soon remembered that the ActionForm is populated and the validate() method is called, all of this before the Action's execute() method is invoked. The question is, do you want to check whether or not the What I suggest is to look at the processPreprocess() method in the RequestProcessor and possibly override this to do your checks. It's called Just some things to think about, Chuck -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: related to: Re: #2 - Use DispatchAction to organize related operations
I have to ask a question; Why not use a filter to handle this? The filter will be called before any components of struts are invoked. It has access to the request, response and session and can handle forwarding the request to the login page or error page if they are not currently logged in. If container managed security is used, it will get invoked prior to the filter, which can then check the getRemoteUser() and the session to ensure that they have been logged in and perform any setup that is required for creating a user object and storing the information in the session or wherever. The filter can then chain to the requested page with the chain.doFilter(). Any reason not to do this? Todd -Original Message- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 7:56 AM To: 'Struts Users Mailing List' Subject: RE: related to: Re: #2 - Use DispatchAction to organize related operations Chuck is absolutely correct on the linear progression of action processing. I, too am overriding processPreprocess and it works beautifully. Besides increasing security, it cuts down on unnecessary CPU bandwidth. Mark -Original Message- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 10:58 PM Rick, catch this earlier. I had implemented something along these lines awhile back and soon remembered that the ActionForm is populated and the validate() method is called, all of this before the Action's execute() method is invoked. The question is, do you want to check whether or not the What I suggest is to look at the processPreprocess() method in the RequestProcessor and possibly override this to do your checks. It's called Just some things to think about, Chuck -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] begin 666 ATT00021.htm M/%$3T-465!%($A434P@4%53$E#((M+R]7,T,O+T141!(5$U,(#,N,B\O M14XB/@T*/$A434P^#0H\2$5!1#X-CQ-151!($A45% M15%5258](D-O;G1E M;G0M5'EP92(@0T].5$5.5#TB=5X=]H=UL.R!C:%RV5T/5=I;F1O=W,M M,3(U,B(^#0H\345402!.04U%/2)'96YEF%T;W(B($-/3E1%3E0](DU3($5X M8VAA;F=E(%-EG9EB!V97)S:6]N(#8N,XU-S8R+C,B/@T*/%1)5$Q%/E)% M.B!R96QA=5D('1O.B!293H@(,R(T@57-E($1IW!A=-H06-T:6]N('1O M(]R9V%N:7IE(')E;%T960@;W!EF%T:6]NSPO5$E43$4^#0H\+TA%040^ M#0H\0D]$63X-CPA+2T@0V]N=F5R=5D(9R;VT@=5X=]P;%I;B!F;W)M M870@+2T^#0H-CQ0/CQ3TY4(%-)6D4],CY)(AA=F4@=\@87-K($@75E MW1I;VX[)FYBW [(%=H2!N;W0@=7-E($@9FEL=5R('1O(AA;F1L92!T M:ES/R9N8G-P.R!4:4@9FEL=5R('=I;P@8F4@8V%L;5D()E9F]R92!A M;GD@8V]M]N96YTR!O9B!S=')U=',@87)E(EN=F]K960N)FYBW [($ET M(AAR!A8V-EW,@=\@=AE(')E75EW0L(')EW!O;G-E(%N9!S97-S M:6]N(%N9!C86X@:%N9QE(9OG=AF1I;F@=AE(')E75EW0@=\@ M=AE(QO9VEN('!A9V4@;W(@97)R;W(@%G92!I9B!T:5Y(%R92!N;W0@ M8W5RF5N=QY(QO9V=E9!I;BXF;F)S#L@268@8V]N=%I;F5R(UA;F%G M960@V5C=7)I='D@:7,@=7-E9P@:70@=VEL;!G970@:6YV;VME9!PFEO MB!T;R!T:4@9FEL=5R+!W:EC:!C86X@=AE;B!C:5C:R!T:4@9V5T M4F5M;W1E57-EB@I(%N9!T:4@V5SVEO;B!T;R!E;G-UF4@=AA=!T M:5Y(AA=F4@8F5E;B!L;V=G960@:6X@86YD('!EF9OFT@86YY('-E='5P M('1H870@:7,@F5Q=6ER960@9F]R(-R96%T:6YG($@=7-EB!O8FIE8W0@ M86YD('-T;W)I;F@=AE(EN9F]R;6%T:6]N(EN('1H92!S97-S:6]N(]R M('=H97)E=F5R+B9N8G-P.R!4:4@9FEL=5R(-A;B!T:5N(-H86EN('1O M('1H92!R97%U97-T960@%G92!W:71H('1H92!C:%I;BYD;T9I;'1EB@I M+CPO1D].5#X\+U ^#0H-CQ0/CQ3TY4(%-)6D4],CY!;GD@F5AV]N(YO M=!T;R!D;R!T:ES/SPO1D].5#X-CPO4#X-@T*/% ^/$9/3E0@4TE:13TR M/E1O90\+T9/3E0^#0H\+U ^#0H-CQ0/CQ3TY4(%-)6D4],CXM+2TM+4]R M:6=I;F%L($UEW-A9V4M+2TM+3PO1D].5#X-@T*/$)2/CQ3TY4(%-)6D4] M,CYF]M.B!'86QBF5A=@L($UAFL@6SQ!($A2148](FUA:6QT;SI'86QB MF5A=A =5SV-O+F-O;2(^;6%I;'1O.D=A;)R96%T:$!T97-S8V\N8V]M M/]!/ET\+T9/3E0^#0H-CQ4CX\1D].5!325I%/3(^4V5N=#H@5'5EV1A M2P@2G5N92 P-P@,C P,B W.C4V($%-/]3TY4/@T*#0H\0E(^/$9/3E0@ M4TE:13TR/E1O.B G4W1R=71S(%5S97)S($UA:6QI;F@3ES=\+T9/3E0^ M#0H-CQ4CX\1D].5!325I%/3(^4W5B:F5C=#H@4D4Z(')E;%T960@=\Z M(%)E.B C,B M(%5S92!$:7-P871C:$%C=EO;B!T;R!OF=A;FEZ92!R96QA M=5D/]3TY4/@T*#0H\0E(^/$9/3E0@4TE:13TR/F]P97)A=EO;G,\+T9/ M3E0^#0H\+U ^#0H\0E(^#0H-CQ0/CQ3TY4(%-)6D4],CY#:'5C:R!IR!A M8G-O;'5T96QY(-OG)E8W0@;VX@=AE(QI;F5AB!PF]GF5SVEO;B!O M9B!A8W1I;VX@')O8V5SVEN9RX\+T9/3E0^#0H-CQ4CX\1D].5!325I% M/3(^22P@=]O(%M(]V97)R:61I;F@')O8V5SU!R97!R;V-EW,@86YD M(ET('=OFMS()E875T:69U;QY+B9N8G-P.R!97-I95S/]3TY4/@T* M#0H\0E(^/$9/3E0@4TE:13TR/FEN8W)E87-I;F@V5C=7)I='DL(ET(-U M=',@9]W;B!O;B!U;FYE8V5SV%R2!#4%4@8F%N9'=I9'1H+CPO1D].5#X- MCPO4#X-@T*/% ^/$9/3E0@4TE:13TR/DUAFL\+T9/3E0^#0H\+U ^#0H- MCQ0/CQ3TY4(%-)6D4],CXM+2TM+4]R:6=I;F%L($UEW-A9V4M+2TM+3PO M1D].5#X-@T*/$)2/CQ3TY4(%-)6D4],CYF]M.B!#:'5C:R!#879A;F5S MR!;/$$@2%)%1CTB;6%I;'1O.F-H=6-K8V%V86YEW- 871T8FDN8V]M(CYM M86EL=\Z8VAU8VMC879A;F5ST!A='1B:2YC;VT\+T$^73PO1D].5#X-@T* M/$)2/CQ3TY4(%-)6D4],CY396YT.B!-;VYD87DL($IU;F4@,#,L(#(P,#(@ M,3 Z-3@@4$T\+T9/3E0^#0H\+U ^#0H-CQ0/CQ3TY4(%-)6D4],CY2:6-K M+#PO1D].5#X-CPO4#X-@T*/% ^/$9/3E0@4TE:13TR/F-A=-H('1H:7,@ M96%R;EEBX@22!H860@:6UP;5M96YT960@V]M971H:6YG(%L;VYG('1H M97-E(QI;F5S(%W:EL92 \+T9/3E0^#0H-CQ4CX\1D].5!325I%/3(^ M8F%C:R!A;F0@V]O;B!R96UE;6)EF5D('1H870@=AE($%C=EO;D9OFT@ M:7,@]P=6QA=5D(%N9!T:4
RE: related to: Re: #2 - Use DispatchAction to organize related operations
hmmm...we actually never use the automatic validation in Struts, preferring to call validateXXX() methods in the ActionForm from the Action (creating and adding to ActionErrors objects), so we can redirect to different pages for different errors (potentially). So the first thing that gets called using this approach is our Action base class's perform() method, yes? This is where we enforce security, and then defer validation calls, redirection, etc., to sub-classes. Chuck is absolutely correct on the linear progression of action processing. I, too am overriding processPreprocess and it works beautifully. Besides increasing security, it cuts down on unnecessary CPU bandwidth. By cutting down on CPU bandwidth, do you mean just because the ActionForm validate() method will never be called for an unauthenticated user? peace, Joe Barefoot -Original Message- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 10:58 PM Rick, catch this earlier. I had implemented something along these lines awhile back and soon remembered that the ActionForm is populated and the validate() method is called, all of this before the Action's execute() method is invoked. The question is, do you want to check whether or not the What I suggest is to look at the processPreprocess() method in the RequestProcessor and possibly override this to do your checks. It's called Just some things to think about, Chuck -- 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]
RE: related to: Re: #2 - Use DispatchAction to organize related operations
Todd, No big ones that I can come up with, other than what Vic was trying to stress about letting the container do the work for you. My comments to Rick were about a specific problem with putting it into the Actions, due to the order of events that take place to process a request. I was just trying to remind Rick that in most cases, the Action is way to late in the process. I think there are several ways to skin this cat. Chuck At 08:19 AM 6/4/2002 -0400, you wrote: I have to ask a question; Why not use a filter to handle this? The filter will be called before any components of struts are invoked. It has access to the request, response and session and can handle forwarding the request to the login page or error page if they are not currently logged in. If container managed security is used, it will get invoked prior to the filter, which can then check the getRemoteUser() and the session to ensure that they have been logged in and perform any setup that is required for creating a user object and storing the information in the session or wherever. The filter can then chain to the requested page with the chain.doFilter(). Any reason not to do this? Todd -Original Message- From: Galbreath, Mark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 7:56 AM To: 'Struts Users Mailing List' Subject: RE: related to: Re: #2 - Use DispatchAction to organize related operations Chuck is absolutely correct on the linear progression of action processing. I, too am overriding processPreprocess and it works beautifully. Besides increasing security, it cuts down on unnecessary CPU bandwidth. Mark -Original Message- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: Monday, June 03, 2002 10:58 PM Rick, catch this earlier. I had implemented something along these lines awhile back and soon remembered that the ActionForm is populated and the validate() method is called, all of this before the Action's execute() method is invoked. The question is, do you want to check whether or not the What I suggest is to look at the processPreprocess() method in the RequestProcessor and possibly override this to do your checks. It's called Just some things to think about, Chuck -- 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]
Re: related to: Re: #2 - Use DispatchAction to organize related operations
Rick, Let me mention something. One potential problem with this approach is that by the time the action is called, may be too late. You really need to catch this earlier. I had implemented something along these lines awhile back and soon remembered that the ActionForm is populated and the validate() method is called, all of this before the Action's execute() method is invoked. The question is, do you want to check whether or not the user is logged in after this, or before it. Maybe this is app specific, I'm not sure. It's my opinion, and only an opinion, that you really should be catching this before the action is invoked, if nothing else, for security reasons. What I suggest is to look at the processPreprocess() method in the RequestProcessor and possibly override this to do your checks. It's called for every request and long before ActionForm's are populated and Action's are invoked. The default value is to return true, which allows request processing to continue. What I've done in the past is to override this, check the login, and possibly redirect the user to the login page. If the user's logged in, just return true to continue processing the request. Just some things to think about, Chuck At 09:31 PM 6/3/2002 -0400, you wrote: On Friday, May 31, 2002, 7:11:47 AM, Ted Husted wrote: TH The Struts Dispatch Action is designed to do exactly the same thing, but TH without messy branching logic. The base perform method will check a TH dispatch field for you, and invoke the indicated method. The only catch TH is that the dispatch methods must use the same signature as perform. TH This is a very modest requirement, since in practice you usually end up TH doing that anyway. Ted, I was discussing with James Mitchell about ways to manage a user being logged in and he suggested a way that I really liked where you have a base class perform method handle checking the login status and then call something like a doWork() method that will invoke the work in your subclass Actions (avoiding have to have all your actions handle the loggin check). The question I have is I'm now using a dispatch action class that handles most of the action work. Do I need to go in and modify the base DispatchAction class' perform method in order to get something similar to the above functionality? Or maybe there is an easier way to handle checking login status using a subclass of DispatchAction? Thanks -- Rick mailto:[EMAIL PROTECTED] Probably the earliest flyswatters were nothing more than some sort of striking surface attached to the end of a long stick. -Jack Handey -- 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]
Re[2]: related to: Re: #2 - Use DispatchAction to organize related operations
On Monday, June 3, 2002, 10:58:07 PM, Chuck Cavaness wrote: CC What I suggest is to look at the processPreprocess() method in the CC RequestProcessor and possibly override this to do your checks. It's called CC for every request and long before ActionForm's are populated and Action's CC are invoked. The default value is to return true, which allows request CC processing to continue. What I've done in the past is to override this, CC check the login, and possibly redirect the user to the login page. If the CC user's logged in, just return true to continue processing the request. Excellent idea. Thanks. You are right I wouldn't even want form validation to take place if they weren't logged in ( which would be allowed to happen if I only checked in the action ). I take it I'll have access to the session as well inside of RequestProcessor, because if I go this route I will also need to check for particular roles that will be stored in a UserBean put in the Session and possibly deny or grant access based on these roles. -- Rick mailto:[EMAIL PROTECTED] I wish I had a dollar for every time I spent a dollar, because then, Yahoo!, I'd have all my money back. -Jack Handey -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re[2]: related to: Re: #2 - Use DispatchAction to organize related operations
The processPreprocess() method has the request and response as arguments, so you should be able to get everything you need. Remember, the method returns a boolean that tells the RequestProcessor whether it should continue to process the request or not. If you find that the user is not logged in, you'll need to return false, but also redirect the user manually. You can still get access to the GlobalForwards and such; it's just that you'll need to take care of the redirecting part. You can call the processActionForward() method and pass it the ActionForward for the login page, for example. Chuck At 11:04 PM 6/3/2002 -0400, you wrote: On Monday, June 3, 2002, 10:58:07 PM, Chuck Cavaness wrote: CC What I suggest is to look at the processPreprocess() method in the CC RequestProcessor and possibly override this to do your checks. It's called CC for every request and long before ActionForm's are populated and Action's CC are invoked. The default value is to return true, which allows request CC processing to continue. What I've done in the past is to override this, CC check the login, and possibly redirect the user to the login page. If the CC user's logged in, just return true to continue processing the request. Excellent idea. Thanks. You are right I wouldn't even want form validation to take place if they weren't logged in ( which would be allowed to happen if I only checked in the action ). I take it I'll have access to the session as well inside of RequestProcessor, because if I go this route I will also need to check for particular roles that will be stored in a UserBean put in the Session and possibly deny or grant access based on these roles. -- Rick mailto:[EMAIL PROTECTED] I wish I had a dollar for every time I spent a dollar, because then, Yahoo!, I'd have all my money back. -Jack Handey -- 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]