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: [email protected]
For additional commands, e-mail: [email protected]
