[jira] [Created] (RAMPART-413) Bad faultCode strings passed to RampartException constructor

["Andrew Janke (JIRA)" <ji...@apache.org>]

Andrew Janke created RAMPART-413:
------------------------------------

             Summary: Bad faultCode strings passed to RampartException constructor
                 Key: RAMPART-413
                 URL: https://issues.apache.org/jira/browse/RAMPART-413
             Project: Rampart
          Issue Type: Bug
    Affects Versions: 1.6.2, 1.6.3
            Reporter: Andrew Janke


RampartException's constructor treats its String argument as an error code that is looked up in a resource bundle. Callers must pass in one of the predefined strings in the resource bundle. But the argument is a regular string so it is not checked at compile time.

Some of the places in the Rampart codebase that call RampartException(str) use bad strings. This causes RampartExceptions to be replaced by RuntimeExceptions thrown by the RampartException constructor, and they have confusing messages complaining about undefined resources.

Here's the places I found. Unless otherwise noted, code and line numbers refer to the code I just checked out of svn on trunk this afternoon.

In RampartMessageData at line 393, it tries passing a normal message string instead of a fault code.

        if (namespace == null || namespace.equals("")) {
            throw new RampartException("Security policy namespace cannot be null.");
        }

This results in the following error for me. (Line numbers refer to the 1.6.2 release.)


Exception java.lang.RuntimeException while pinging MarketInfo service status
java.lang.RuntimeException: Undefined 'Security policy namespace cannot be null.' resource property
	at org.apache.rampart.RampartException.getMessage(RampartException.java:81)
	at org.apache.rampart.RampartException.<init>(RampartException.java:41)
	at org.apache.rampart.RampartException.<init>(RampartException.java:57)
	at org.apache.rampart.RampartMessageData.setWSSecurityVersions(RampartMessageData.java:387)
	at org.apache.rampart.RampartMessageData.<init>(RampartMessageData.java:261)
	at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:61)
	at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:65)

* At rampart-core/src/main/java/org/apache/rampart/builder/AsymmetricBindingBuilder.java:138, "rampartConigMissing" is misspelled, but it's misspelled the same way in the resource file, so it'll still work.


rampart-core/src/main/java/org/apache/rampart/builder/SymmetricBindingBuilder.java:752:
            throw new RampartException("noSHA1availabe", e1);
* This has misspelled "available", and the fault code is not present in errors.properties under either spelling.

rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java:249:
            throw new RampartException("unexprectedSignature");
* Misspelled "unexpected", but matches errors.properties.

rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java:271:
                throw new RampartException("unexprectedEncryptedPart");
* Misspelled "unexpected", but matches errors.properties.

rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java:486:
                throw new RampartException("An error occurred while searching for decrypted elements.", e);
* Plain error message instead of fault code, will raise runtime error.

rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java:546:
                throw new RampartException("An error occurred while searching for decrypted elements.", e);
* Plain error message instead of fault code, will raise runtime error.

rampart-core/src/main/java/org/apache/rampart/RampartMessageData.java:403:
            throw new RampartException("Invalid namespace received, " + namespace);
* Plain error message instead of fault code, will raise runtime error.


rampart-core/src/main/java/org/apache/rampart/RampartMessageData.java:393: 
           throw new RampartException("Security policy namespace cannot be null.");
* Plain error message instead of fault code, will raise runtime error. This is the one I ran in to in practice in 1.6.2 and noted above.


rampart-core/src/main/java/org/apache/rampart/util/MessageOptimizer.java:69:
			throw new RampartException("Error in XPath ", e);
* Plain error message instead of fault code, will raise runtime error.

rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java:493:            throw new RampartException("Error Retrieving the policy from mex", e);
rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java:495:            throw new RampartException("Error Retrieving the policy from mex", e);
* Plain error message instead of fault code, will raise runtime error.


There may be more that I didn't catch; I just did a simple grep for "new RampartException" and skimmed through the results.

If you want to do this layer of indirection, there's a couple things you could do to catch these errors earlier.

* Instead of having RampartException take a string, define a RampartFaultCode type that wraps the string. This will make it clear to callers that they can't pass in arbitrary error messages, which they may be used to doing since most exception constructors take those. You could also optionally supply a RampartException(String) constructor to allow arbitrary non-translated messages.

* Make RampartFaultCode an enumerated type and have callers refer to the enumerated instances like `RampartFaultCode.noSecurityToken` instead of `RampartFaultCode("noSecurityToken")`. This would catch typos or bad names at compile time.

* At run time, when RampartException loads in the errors.properties resource bundle while initializing the class, it could check to ensure that all of the enumerated codes in RampartFaultCode are actually present in the resource bundle, and throw an exception if they're not. This way you'd be testing up front that all your fault codes have translation strings defined, instead of depending on code path coverage in your testing or unusual user situations to hit the cases where the resource bundle is missing a code or has a typo.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org