Hello
We are currently using Oxalis 3.2, and noticed a couple of problems with SMP lookup. They were discovered during some internal test runs, and therefore we have not yet seen the problem in production. The issues will only appear in special circumstances, when the SMP registration is done in a valid (but not normally used) way.
If we look at the following registration in the SMP:
http://b-ddc207601e442e1b751e5655d39371cd.iso6523-actorid-upis.edelivery.tech.ec.europa.eu/iso6523-actorid-upis%3A%3A9908%3A810017902/services/busdox-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3ACreditNote-2%3A%3ACreditNote%23%23urn%3Awww.cenbii.eu%3Atransaction%3Abiitrns014%3Aver2.0%3Aextended%3Aurn%3Awww.cenbii.eu%3Aprofile%3Abiixx%3Aver2.0%3Aextended%3Aurn%3Awww.difi.no%3Aehf%3Akreditnota%3Aver2.0%3A%3A2.1
We can see that in the ns3:ProcessList that only one ns3:Process exist. In the test performed, there was two ns3:Process elements. The second ns3:Process element contains the information we need.
However in the oxalis-common class eu.peppol.smp.SmpLookupManagerImpl we have found this code
EndpointType selectOptimalEndpoint(SignedServiceMetadataType serviceMetadata) {
// List of end points contained in the signed service meta data type
List<EndpointType> endPointsForDocumentTypeIdentifier = serviceMetadata
.getServiceMetadata()
.getServiceInformation()
.getProcessList()
.getProcess()
.get(0)
.getServiceEndpointList()
.getEndpoint();
...
where the code always take the first ns3:Process element from the process list and we need the second element.
Described below are the first errors:
1 - The first ns3:Process element could be the old START protocol, while the second could be AS2 protocol. So the code should loop through the list and find only those that have an accepting protocol.
2 - The method does not validate the profile. The first ns3:Process element could be a undesired profile, while a later ns3:Process element could be the desired ns3:Process element.
Another error related to above errors were found in the class eu.peppol.smp.DefaultBusDoxProtocolSelectionStrategyImpl, as showed below. However this error could also be described as an invalid SMP registration, but Oxalis should still handle this in a valid way.
@Override
public BusDoxProtocol selectOptimalProtocol(List<BusDoxProtocol> protocolsAccepted) {
int lowestIndex = Integer.MAX_VALUE;
for (BusDoxProtocol busDoxProtocol : protocolsAccepted) {
int indexOf = knownProtocols.indexOf(busDoxProtocol);
if (indexOf == -1) {
throw new IllegalArgumentException("BusDox protocol " + busDoxProtocol + " not known by protocol selection strategy");
}
if (indexOf > -1 && indexOf < lowestIndex) {
lowestIndex = indexOf;
}
}
return knownProtocols.get(lowestIndex);
}
The error we received was:
Caused by: java.lang.ArrayIndexOutOfBoundsException: 2147483647
at java.util.Arrays$ArrayList.get(Unknown Source) ~[na:1.8.0_101]
at eu.peppol.smp.DefaultBusDoxProtocolSelectionStrategyImpl.selectOptimalProtocol(DefaultBusDoxProtocolSelectionStrategyImpl.java:55) ~[oxalis-commons-3.2.0.jar:na]
If we look at the class, the index is first set to 2147483647 ( Integer.MAX_VALUE). In the ns2:Process element, the ns2:ServiceEndpointList element contains no ns2:Endpoint element.
The method just jump to:
knownProtocols.get(lowestIndex);
and the lowestIndex is still 2147483647, so it result in an ArrayIndexOutOfBoundsException.
Jacob Mogensen
mySupply ApS
Denmark
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent