axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Janke (JIRA)" <j...@apache.org>
Subject [jira] [Created] (RAMPART-413) Bad faultCode strings passed to RampartException constructor
Date Tue, 01 Apr 2014 20:30:16 GMT
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


Mime
View raw message