Stripes

_sourcePage passed request parameter via Javascript is having some exception on server side validation during getSourcePage

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: Release 1.5.1, Release 1.6
  • Component/s: Validation
  • Labels:
    None
  • Environment:
    Tomcat 6.0.16,
    jdk1.6.0_05,
    Stripes 1.5b1.
    Eclipse 3.3.2.
    Windows XP.
    Internet Explorer 6.0

Description

Hi,

Currently having an error during validation with errors and calling the getContext().getSourcePageResolution() in an ActionBean.. The exception trace..
Bad Base64 input character at 0: 47(decimal)
15:14:30,117 DEBUG ExecutionContext:150 - Transitioning to lifecycle stage RequestComplete
15:14:30,117 WARN DefaultExceptionHandler:39 - Unhandled exception caught by the Stripes default exception handler.
java.lang.IllegalArgumentException: Null input buffer
at javax.crypto.Cipher.doFinal(DashoA13*..)
at net.sourceforge.stripes.util.CryptoUtil.decrypt(CryptoUtil.java:188)
at net.sourceforge.stripes.action.ActionBeanContext.getSourcePage(ActionBeanContext.java:249)
at net.sourceforge.stripes.action.ActionBeanContext.getSourcePageResolution(ActionBeanContext.java:226)
....
...
...

This only happens after a first load of my page. I have an href that have an image that has an onclick that triggers a javascript. Then in my javascript function I have Ajax.Updater method

var params = 'initVar&id=' + nId
+ '&_sourcePage=\/bugMaintenance.jsp';

new Ajax.Updater( "", "${pageContext.request.contextPath}/ctrlr/BugMaint.action",
{ method: 'post', postBody: params, onSuccess: successAddFunc, onFailure: errorAddFunc });

I know this might is not the clean way, but do you have any ideas what is wrong? Or any suggestion how to do this via Ajax to pass the _sourcePage?

I tried to debug the source code of stripes. The problem is on the ActionBeanContext.getSourcePage(). during the call to CryptoUtil.decrypt(sourcePage), since I did not encrypt the _sourcePage which I just tweaked and passed as request parameter during an Ajax call, the processing throws a Null pointer somewhere inside the decrypting of the source page.
Inside the decrypt(String) method of CryptoUtil, the Base64.decode(input, BASE64_OPTIONS) returned null.

Thanks,
--jg

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kai Grabfelder added a comment - 02/May/08 8:49 AM

I just encountered the same issue. Besides encrypting the sourcePage parameter you could also do the following: use your own subclass of ActionBeanContext storing a Resolution:

public class MyActionBeanContext extends ActionBeanContext {

private Resolution sourcePageResolution;

@Override
public Resolution getSourcePageResolution() { if (sourcePageResolution != null) return sourcePageResolution; return super.getSourcePageResolution(); }

public void setSourcePageResolution(Resolution sourcePageResolution) { this.sourcePageResolution = sourcePageResolution; }

}

in your action you could then do:

MyAction implements ActionBean{
MyActionBeanContext context;

final public void setContext(ActionBeanContext context) { this.context = (MyActionBeanContext) context; context .setSourcePageResolution("\/bugMaintenance.jsp"); }

}

Besides this workaround: shouldn't we should return the input value if we can't decrypt it? See the attached patch for a possible solution

Show
Kai Grabfelder added a comment - 02/May/08 8:49 AM I just encountered the same issue. Besides encrypting the sourcePage parameter you could also do the following: use your own subclass of ActionBeanContext storing a Resolution: public class MyActionBeanContext extends ActionBeanContext { private Resolution sourcePageResolution; @Override public Resolution getSourcePageResolution() { if (sourcePageResolution != null) return sourcePageResolution; return super.getSourcePageResolution(); } public void setSourcePageResolution(Resolution sourcePageResolution) { this.sourcePageResolution = sourcePageResolution; } } in your action you could then do: MyAction implements ActionBean{ MyActionBeanContext context; final public void setContext(ActionBeanContext context) { this.context = (MyActionBeanContext) context; context .setSourcePageResolution("\/bugMaintenance.jsp"); } } Besides this workaround: shouldn't we should return the input value if we can't decrypt it? See the attached patch for a possible solution
Hide
Permalink
Kai Grabfelder added a comment - 02/May/08 8:51 AM

possible patch...

Show
Kai Grabfelder added a comment - 02/May/08 8:51 AM possible patch...
Hide
Permalink
Scott Van Wart added a comment - 02/May/08 3:01 PM

I think the first solution (ActionBeanContext) is a much better solution. Though personally I would just override getSourcePage(), which is where the decoding is handled directly. There is a problem with the submitted patch--what if the source page contains only A-Z, a-z, 0-9, + and / (all 64 valid characters of base64)? Personally mine are all likely to end with .jsp, so in an ideal situation I might be able to rely on that, but I think a more context-sensitive solution (subclassing ActionBeanContext) is appropriate.

I personally think a failed decoding should throw a more legible exception (rather than letting CryptoUtil catch the error and throwing a cryptic-no pun intended-exception about a null input buffer). This would get hit in 2 cases:
1) The developer forgot to circumvent the encoding/decoding (e.g. by the above example, or by overriding getSourcePageResolution).
2) The web user decided to try and be funny and edited the _sourcePage attribute in the URL (easy to do in GET requests).

The first case should simply be failfast--it's a programming error. In the second case it might be useful to catch a more specific exception (rather than IllegalArgumentException thrown by CryptoUtil), and then (at the end-developer's preference) spit out an error to discourage the user from mucking about with server-side state handed to the client.

Show
Scott Van Wart added a comment - 02/May/08 3:01 PM I think the first solution (ActionBeanContext) is a much better solution. Though personally I would just override getSourcePage(), which is where the decoding is handled directly. There is a problem with the submitted patch--what if the source page contains only A-Z, a-z, 0-9, + and / (all 64 valid characters of base64)? Personally mine are all likely to end with .jsp, so in an ideal situation I might be able to rely on that, but I think a more context-sensitive solution (subclassing ActionBeanContext) is appropriate. I personally think a failed decoding should throw a more legible exception (rather than letting CryptoUtil catch the error and throwing a cryptic-no pun intended-exception about a null input buffer). This would get hit in 2 cases: 1) The developer forgot to circumvent the encoding/decoding (e.g. by the above example, or by overriding getSourcePageResolution). 2) The web user decided to try and be funny and edited the _sourcePage attribute in the URL (easy to do in GET requests). The first case should simply be failfast--it's a programming error. In the second case it might be useful to catch a more specific exception (rather than IllegalArgumentException thrown by CryptoUtil), and then (at the end-developer's preference) spit out an error to discourage the user from mucking about with server-side state handed to the client.
Hide
Permalink
J G added a comment - 07/May/08 9:42 AM

Thanks Scott and Kai,

I have followed Kai's idea, overriding getSourcePageResolution and setSourcePageResolution in my own ActionBeanContext. And in my ActionBean I have overriden setContext and getContext. It seems ok when I tried to debug. But the errors are not showing up in the browser. I am wondering if this got to do with Ajax updating the UI or a browser problem perhaps..?

I even tried to debug the normal flow that does not use Ajax .. for example coming from a click of a submit button implemented in Stripes and having known errors in the form. The sequence of events/flows is the same with the Ajax way of submitting.

Then for Scott's comment, I have done that one like overriding getSourcePage and having a catch Exception just to catch CryptoUtil's exception and just returning the un-encrypted source page if it have thrown an exception. But still the same thing happens.

I wonder if anyone have experienced doing Ajax together with Stripes and if they have resolved a similar problem that I am encountering.

Thanks,
J G

Show
J G added a comment - 07/May/08 9:42 AM Thanks Scott and Kai, I have followed Kai's idea, overriding getSourcePageResolution and setSourcePageResolution in my own ActionBeanContext. And in my ActionBean I have overriden setContext and getContext. It seems ok when I tried to debug. But the errors are not showing up in the browser. I am wondering if this got to do with Ajax updating the UI or a browser problem perhaps..? I even tried to debug the normal flow that does not use Ajax .. for example coming from a click of a submit button implemented in Stripes and having known errors in the form. The sequence of events/flows is the same with the Ajax way of submitting. Then for Scott's comment, I have done that one like overriding getSourcePage and having a catch Exception just to catch CryptoUtil's exception and just returning the un-encrypted source page if it have thrown an exception. But still the same thing happens. I wonder if anyone have experienced doing Ajax together with Stripes and if they have resolved a similar problem that I am encountering. Thanks, J G
Hide
Permalink
Ben Gunter added a comment - 22/Oct/08 2:17 PM

This is fixed for 1.5.1 and later. The patch suggested the possibility of returning the input string if it is not encrypted/encoded. That would defeat one of the purposes of encryption: preventing users from submitting a parameter value other than the one the developer intended.

Show
Ben Gunter added a comment - 22/Oct/08 2:17 PM This is fixed for 1.5.1 and later. The patch suggested the possibility of returning the input string if it is not encrypted/encoded. That would defeat one of the purposes of encryption: preventing users from submitting a parameter value other than the one the developer intended.

People

  • Assignee:
    Unassigned
    Reporter:
    J G
Vote (1)
Watch (1)

Dates

  • Created:
    28/Apr/08 3:07 PM
    Updated:
    04/Jan/11 3:10 PM
    Resolved:
    22/Oct/08 2:17 PM
Atlassian JIRA (v4.2#587) | Report a problem
Powered by a free Atlassian JIRA open source license for Stripes Framework. Try JIRA - bug tracking software for your team.