Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Meridian-2016.1.6, Meridian-2017.1.1
-
Security Level: Default (Default Security Scheme)
-
Horizon - November 1st
Description
Let's say an operator is managing the inventory through the ReST API directly as he is in the process of developing a script to populate the requisitions in OpenNMS.
The following XML is actually a valid content when querying /opennms/rest/nodes,
<node label="bad-node" foreignSource="Test" building="Office" type="A" foreignId="bad-node" />
It is good for that end point, as that is a partial representation of the OnmsNode object. Now, a user might try to use this wrong object against /opennms/rest/requisitions, which is not going to work as that is not a representation of a RequisitionedNode object.
The problem is that the API won't complain and will accept the request:
[root@meridian2016 ~]# curl -u admin:admin -v -H 'Content-Type: application/xml' -d @bad-node.xml http://localhost:8980/opennms/rest/requisitions/Test/nodes * About to connect() to localhost port 8980 (#0) * Trying ::1... * Connected to localhost (::1) port 8980 (#0) * Server auth using Basic with user 'admin' > POST /opennms/rest/requisitions/Test/nodes HTTP/1.1 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.29.0 > Host: localhost:8980 > Accept: */* > Content-Type: application/xml > Content-Length: 96 > * upload completely sent off: 96 out of 96 bytes < HTTP/1.1 202 Accepted < Location: http://localhost:8980/opennms/rest/requisitions/Test/nodes < Date: Tue, 31 Oct 2017 20:36:04 GMT < Content-Length: 0 < Server: Jetty(8.1.10.v20130312) < * Connection #0 to host localhost left intact
The above assumes that I've saved the XML on a file called bad-node.xml.
Now, if I try to perform a GET request against the requisitions end point for the requisition in question, it fails and returs an HTTP 500 error.
Checking the logs, I found the problem on the attached web.log.
From now on, the ReST end point for the affected requisition is unusable until opennms is restarted.
I think the ReST end point should validate the XML input and reject it when it is malformed, which is not the case, hence the exception:
2017-10-31 16:36:25,228 ERROR [qtp216652079-786 - /opennms/rest/requisitions/Test] o.a.c.i.AbstractFaultChainInitiatorObserver: Error occurred during error handling, give up!
org.apache.cxf.interceptor.Fault
...
Caused by: java.lang.NullPointerException
at org.opennms.netmgt.provision.persist.AbstractForeignSourceRepository.validate(AbstractForeignSourceRepository.java:150) ~[opennms-provision-persistence-2016.1.8.jar:?]
at org.opennms.netmgt.provision.persist.FilesystemForeignSourceRepository.save(FilesystemForeignSourceRepository.java:308) ~[opennms-provision-persistence-2016.1.8.jar:?]
at org.opennms.web.svclayer.support.DefaultRequisitionAccessService$RequisitionAccessor.flush(DefaultRequisitionAccessService.java:471) ~[opennms-web-api-2016.1.8.jar:?]
at org.opennms.web.svclayer.support.DefaultRequisitionAccessService$RequisitionAccessor.getRequisition(DefaultRequisitionAccessService.java:418) ~[opennms-web-api-2016.1.8.jar:?]
at org.opennms.web.svclayer.support.DefaultRequisitionAccessService$8.call(DefaultRequisitionAccessService.java:632) ~[opennms-web-api-2016.1.8.jar:?]
at org.opennms.web.svclayer.support.DefaultRequisitionAccessService$8.call(DefaultRequisitionAccessService.java:630) ~[opennms-web-api-2016.1.8.jar:?]
