Rex Norm

Hi,

I inherited a struts 1.3.10 app., and I'm trying to streamline all the classes with DispatchAction.

The current app has a class structure that looks like this:
appplicationClassXYZ (there are a lot of these) --> rootAction --> Action

rootAction is where admin duties are handled (in the execute() method) -- logging, checking that user is logged in, other junk ( filters may be best for some of this). To put all of these classes into one class, I notice from the Struts docs that I need to extend DispatchAction, but I don't override the execute() method or even deal with it in the subclass. So, the question is how can I handle admin duties such that every time superclass is called, the admin stuff, logging, etc. is taken care of? That is, don't I need to extend the execute() method? or do I put the admin stuff in a separate method in rootAction and be sure to call it for every method when I extend the DispatchAction? Seems like I should be able to encapsulate this.

this should be simple, but I'm not getting it. Just not sure how exactly DispatchAction works.

_Rex

Yes, I think that's the way to do it. It's relatively independent, and scales well, even if I move to later versions / frameworks.

thanks!

_R

Thanks, and I did see that post. Honestly, I **DON'T** want to get intimate with the Token, and in fact, I do use the form tag.

All I want is to get a pleaseWait page to work, but I keep losing the token in the Meta refresh.

The best I can do is to show a pleaseWait page with an action that checks the token (works here), and then call another action that takes a while with the meta tag. Trouble is, I check the token in the downstream action too and it always fails. The token in the request is null, but the one in the session is fine . So, I figured I ought to pass the token by doing a bit of URL rewriting in the META tag, but this isn't very elegant IMHO.

Open to other suggestions ... tried the longWaitRequestProcessor, but it uses the same META refresh approach. There is the servlet approach, but this requires hard-coding of html and more lower-level coding that at the level of actions. Not against it, but looking for something reproducible, other than moving to Struts2 or other framework. LongWaitRequestProcessor was a good option.

_R

I'm having trouble implementing a PleaseWait page using Struts 1.3.10.

I have an SetupAction that calls saveToken(request) then displays a userEntry.jsp (using GET). I can see the TOKEN in the page source. I then POST to an action that checks the token, redirects to a PleaseWait page. This PleaseWait page then Meta refreshes to the actual ProcessOrderAction which takes a while.

Looks like this:

SetupAction --> saveToken(req) --> userEntry.jsp (GET)
UserEntry.jsp --> POSTs to --> PleaseWaitAction --> pleaseWait.jsp (GET)--> META REFRESH --> ProcessOrderAction

I can see the token (on the page source) up to the PleaseWaitAction, but I seem to lose the token when I go to the ProcessOrderAction.

Three questions:

where in the request do I look for the token? I use eclipse' debugger, and I've tried looking through all the request parameters. I can't find it. I find the token in the session, but not the request. Is it in the POST data? if so, how do I decipher it?

What can I do to get my ProcessOrderAction to see the token in the request?

Is there an easier way to handle long-running actions that can't be split up? Note that I'm stuck with an older version of struts

I've also tried extending the request processor to a LongWaitRequestProcessor, but I ran into the same problem. If I add the session token to the queryString on the pleaseWait.jsp , I can pass the token, but then the downstram TOKEN check never fails-- that is, I always seem to have a valid token.

Where am I going wrong and how can I find the TOKEN in the post data to help me debug this?

Apologies if this has been covered, but I couldn't find it in my searches.

I have implemented a PRG pattern for a sales funnel... my last action takes a while, so I've implemented a PleaseWait page with a meta refresh that hangs on the final action's completion. However, I can't get the saveToken to work for the double submit. Using a debugger, I see that the request for Submit Order has no token, but the session does.

I've added an <html:form></html:form> to my meta refresh page, but I think my problem is that the PleaseWait page doesn't POST to the submitOrder action.

Any thoughts on how I could make the Meta refresh work for the action that takes a while AND get the token working?? I'm open to an alternate design too... thanks in advance for the brainpower.

_R


<!-- takes the order, calculates the charges and creates a bill. --> <action path="/storeIt/GetPricing" type="com.s2s.purchase.GetPricingAction" name="EnterOrderForm" scope="request" validate="true" input=".storeIt.landing" > <set-property property="secure" value="true" /> <forward name="success" path="/storeIt/DisplayPricing.s2s" redirect="true" /> </action> <!-- just shows the result --> <action path="/storeIt/DisplayPricing" type="com.s2s.purchase.DisplayAction" name="EnterOrderFormOut" scope="request" input="/storeIt/EditOrder.s2s" validate="false" > <set-property property="secure" value="true" /> <forward name="success" path=".storeIt.GetPricing" redirect="false" /> </action> <!-- shows a 'please wait' page with meta refresh to next action --> <action path="/storeIt/DisplayPleaseWait" type="com.s2s.purchase.DisplayPleaseWaitAction" name="EnterOrderForm" scope="request" input="/storeIt/DisplayPricing.s2s" validate="true" > <set-property property="secure" value="true" /> <forward name="success" path=".storeIt.PleaseWait" redirect="false" /> <forward name="error" path=".errors.landing" redirect="true" /> </action> <!-- does the actual processing of the order... takes a while --> <action path="/storeIt/SubmitOrder" type="com.s2s.purchase.SubmitOrderAction" name="EnterOrderForm" scope="request" > <set-property property="secure" value="true" /> <forward name="success" path="/storeIt/DisplayThankYou.s2s" redirect="true" /> <forward name="error" path=".errors.landing" redirect="true" /> </action>

The relevant portions of the Actions:

public class GetPricingAction extends PurchaseRootAction { public ActionForward purchasePerform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response, UnThreadsafeObjects unThreadsafeObjects) throws Exception { ... saveToken(request); return success(mapping); } public class DisplayAction extends PurchaseRootAction { public ActionForward purchasePerform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response, UnThreadsafeObjects unThreadsafeObjects) throws IllegalAccessException, InvocationTargetException { ... // does nothing with the TOKEN. return success(mapping); } public class DisplayPleaseWaitAction extends PurchaseRootAction { public ActionForward purchasePerform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response, UnThreadsafeObjects unThreadsafeObjects) throws Exception { if(isTokenValid(request)){ //Business actions.. resetToken(request); saveToken(request); return mapping.findForward("success"); // displays the pleaseWait page with meta refresh... }else{ // generate error and send to global error page ActionMessages messages = new ActionMessages(); messages.add(ActionMessages.GLOBAL_MESSAGE, new ActionMessage ("errors.duplicate.submission")); this.saveErrors(request.getSession(), messages); return mapping.findForward("error"); } }

I use Struts 1.3.10.

I have a form where users add data-entry rows and fill out data about an order item. Rows can be added or deleted.
I've defined an OrderForm (a bean, extends ValidatorActionForm) that has an ArrayList of OrderItem beans. The idea is that as rows of order items are added by the user, the ArrayList<OrderItem> captures them.

The form works well, but, when I run with validation, I get bizarre behavior:

- if a user submits a blank row or sets of fields, validation works. But if the user decides to delete that row and resubmit, the validation behaves as if the row were still present and kicks out a validation asking for field values. Even if I add a row, I can't get out of this loop... I have to logout and restart a new session to enter data.

It seems that the ActionForm is out of sync with the UI. I've tried placing the form in session scope and request scope... same problem.

Any idea what is going on? My impression is that a new form should be submitted, but it's acting like the old one is.

I think I'm unclear on the order of operations for validation-- is it:
1.) instantiate bean
2.) run validator
3.) if validator passes, then process to the next Action
4.) if validator fails, then kick back to prior jsp?

Would implementing the .reset() method help?

thanks in advance.

_R

Mike, thanks for your response.

You should never perform url rewriting

I plan to avoid this.

If you are creating URLs in a Servlet, ...

yes, this is my intent... I need to redirect from an insecure page to a secure login page (SSL) and then redirect to another secure page on success.

...you should use the javax.servlet.http.HttpServletRequest encodeURL method. In a JSP you should use the JSTL url tag <c:url> example.

So does this mean that the same sessionId is used for both http and https? Meaning that a redirect from http --> https will be handled by the tag and container? I seemed to read somewhere that setting a new sessionId is a good idea for the secure component. I guess nothing is preventing me from setting a new cookie with a new (self generated) ID with quick expiration for the secure part and relying on that, right?

Also, is there a difference between <html:link> and <c:url>? do they do the same thing?


thanks for your help.
_R

Sorry one more question to be complete-- is the behavior different when coming from https:// and redirecting (or forwarding??) to http://?

that is, is jsessionID (URL rewriting) used in the reverse direction or can the cookie be used? Can I force this?

thanks,

_r

Let's say that I've never visited a site, and I go to it using http://mysite.com.

The servlet container is supposed to assign a jsessionId and try to set a cookie. If I have cookies enabled, I should no longer see the jsessionId, correct?

Now, what happens when I redirect (or forward) from a page on http://mysite.com/servlet1 to another https://mysite.com/servlet2? Will URL rewriting kick in? Will the SAME sessionId be used (and is this good practice in terms of security?)

If URL rewriting does kick in for the scheme change (http --> https), should i expect it to break my URLs by adding the ";jsessionId=xxxx"? and what can I do to prevent this? (servlet filter to intercept and strip this out)?

I would even appreciate an RTFM reference if this is too basic.

thanks in advance.

_R

Oh, I should add that the appropriate action is that by calling https://www.mysite.com/storeIt/landing.s2s

I should be redirected to https://www.mysite.com/login.s2s?redirect="/storeIt/landing.s2s"

I have some links on a home page that are called as follows:
<html:link action="/landing" styleClass="...>description</html:link>

When the user comes to the site for the first time (no cookie set yet), they get a jsessionId assigned. All pages are served by servlets. Most of the links work fine, but the ones that lead to a servlet that redirects to an https login page have the jsessionID embedded in their url. Thus, they break and I get a 404 error. Earlier, i was able to even see the home page's source that showed the embedded jsessionId, but I think my using the <html:link> tag fixed that.

Here is the header trace -- I'm at a loss as to why the jessionId is being made part of the URL when cookies are working fine:

This is the home page... working as it should. Cookie is set, and we're ok.
http://www.mysite.com/ GET / HTTP/1.1 Host: www.mysite.com User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive HTTP/1.1 200 OK Date: Wed, 18 May 2011 03:44:19 GMT Server: Apache Vary: * Set-Cookie: JSESSIONID=CBB8D83C0A89B6E494F7C986A789D60F; Path=/; HttpOnly Keep-Alive: timeout=5, max=50 Connection: Keep-Alive Content-Type: text/html;charset=UTF-8 Content-Encoding: gzip Content-Length: 4060 ----------------------------------------------------------

Now with the servlet that redirects to an https login page (with a redirect back to the referring page on success), I get this -- note the URL with jsessionId embedded.
http://www.mysite.com/storeIt/landing.s2s //get the servlet, and have it redirect to login page. GET /storeIt/landing.s2s HTTP/1.1 Host: www.mysite.com User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://www.mysite.com/ Cookie: JSESSIONID=CBB8D83C0A89B6E494F7C986A789D60F HTTP/1.1 302 Moved Temporarily Date: Wed, 18 May 2011 03:46:13 GMT Server: Apache Location: https://www.mysite.com/storeIt/landing.s2s;jsessionid=CBB8D83C0A89B6E494F7C986A789D60F // note sessionId appended to URL!!! Content-Length: 0 Keep-Alive: timeout=5, max=50 Connection: Keep-Alive Content-Type: text/html ----------------------------------------------------------

Now the browser tries to get this bad url and fails...
https://www.mysite.com/storeIt/landing.s2s;jsessionid=CBB8D83C0A89B6E494F7C986A789D60F GET /storeIt/landing.s2s;jsessionid=CBB8D83C0A89B6E494F7C986A789D60F HTTP/1.1 Host: www.mysite.com User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip, deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 115 Connection: keep-alive Referer: http://www.mysite.com/ Cookie: JSESSIONID=CBB8D83C0A89B6E494F7C986A789D60F HTTP/1.1 404 Not Found Date: Wed, 18 May 2011 03:46:13 GMT Server: Apache Content-Length: 1150 Keep-Alive: timeout=5, max=50 Connection: Keep-Alive Content-Type: text/html;charset=utf-8 ----------------------------------------------------------

Any thoughts on why this would occur, and what I can do to prevent it? My impression is that the Struts framework (1.3.10 is what I use) should handle the URL rewriting if I use the right tags... maybe I'm not?

I'm happy to post the redirect code, but I figure this post is long enough.
_R

I'm quite confused about encoding, and I wonder if there is a preferred encoding for Struts (1.3.10 is what I use):

The servlet spec says iso=8859-1, and I notice that many libraries to be used with Struts use utf-8.

I also notice that I'm getting some problems with jsessionId being appended to servlet urls and breakign them (cookies are enabled). I think this may be due to the encoding used. I realize that the first time, if no cookie is set, the jsessionId should be used. However, this continues to be used even with cookies turned on.

All my links are served by servlets. If I code a link as follows:

<html:link action="/landing" styleClass="${tab1TextClass}" >Welcome</html:link>

the page source is served up differently depending on the encoding:
Under content="text/html;charset=utf-8":
// note appended jsessionid as part of url-- this DOES NOT WORK <a href="/landing.s2s;jsessionid=D22AA3B781638BF4A56915D25E3F9D59" class="selected">Welcome</a>
when set to content="text/html;charset=iso-8859-1"
// this works <a href="/landing.s2s" class="selected">Welcome</a>

Sticking to the standard seems to make sense, but is there some advantage to utf-8??? I realize that I can accept both, but if one affects my urls, is there any advantage of doing this?

Maybe there is something else I'm missing??

_R

OK.... more info. I downloaded the source, and it seems that they DO hardcode the ports (http = port 80; https = 443). Setting these in the struts config per their example doesn't seem to do anything.

I've set my server.xml on tomcat to run on 80/443 and it now seems to work.

_R

I should also mention that I'm on struts 1.3.10 using the composableRequestProcessor.

Hi all,

I'm using sslext to control ssl use on my site. I think I've installed it correctly, based on the scanty documentation available. However, it seems to be losing the port number during the url rewrite.

I'm running on localhost:8080 (a development machine) and I've got ssl installed on port 443 using Tomcat's keystore (self signed cert that has been installed in the browser)

In my action config, I have:

<action path="/someAction" type="com.mysite.web.login.someAction" name="someForm" scope="request" validate="false" > <set-property property="secure" value="true" /> <forward name="success" path=".a.landing.page" redirect="false" /> </action>

When I follow a link to this form, the browser gives me: https://localhost/someAction;(some session ID) -- this then gets set to cookies after the first page. I think I'm ok with this, and this seems to be normal container behavior too.

When i go to a page handled by an UNSECURE action:

<action path="/someAction2" type="com.mysite.web.login.someAction2" name="someForm" scope="request" validate="false" > <set-property property="secure" value="false" /> <forward name="success" path=".another.landing.page" redirect="false" /> </action>

I get: http://localhost/someAction2;sessionID (and no page comes up).

Is this hardcoded in the sslext library? As a workaround, I tried to get my Eclipse-controlled Tomcat environment to work on port 80, but I keep getting errors that there is another server operating on port 80 (I have none-- I can only think that Eclipse has soemthing to do with this).

ANy thoughts on how I can:
1.) get appropriate port rewriting (if that is the problem)? Is this a Tomcat config problem? the scheme rewriting seems to work (e.g. http --> https and back)
2.) how to get port 80 to work to test it (or to get 8080 to work).

_r

PS as an aside, one reason I used 443 is that 8443 was giving all sorts of behavior, which led me to believe that ports were being lost in the rewrite.