IBM Security SOAR

Expand all | Collapse all

Got 500 when posting attachment to incident

Jump to Best Answer
  • 1.  Got 500 when posting attachment to incident

    Posted Thu May 14, 2020 10:33 AM
    Hi, we are integrating Guardium with Resilient. We are trying to create an incident, and attach a pdf file to the incident. We use java REST API to post the attachment. But in both the Guardium application java codes, and on the "Resilient Systems REST API" page, I got 500 response code and the following response body:
    { "success": false,
       "
    title": null,
       "
    message": "Internal Server Error",
       "
    hints": [],
       "
    error_code": "generic"
    }


    The following is the request from our java app that  attaches the pdf file to the incident (which has ID=2000):
    1. I made a call to "/rest/session" to get back CSRFToken and JSessionId first.
    2. Create HttpPost request with this URI:
         "https://<resilientHost>/rest/orgs/201/incidents/2000/attachments"
    3. Set the following to the request:
    • add header: "Accept": "application/json"
    • add header: "Content-Type": "application/pdf"
    • add header: "Cookie": "JSESSIONID=<JSessionId>"
    • add header: "x-sess-id": <CSRFToken>
    • set Entity with the FileEntity object of the pdf file
    4. Call the HttpClient.execute(<the above HttpPost request>)
    (The HttpClient is created with "TLSv1.2".)

    This execute() returns 500 response code.

    The Resilient server is Version: 35.2.32. I logged in as a "Master Administrator".
    What was missing or incorrect in the above codes to send attachment to incident? Is there any sample java codes that do this? 

    Please help, thanks!



    ------------------------------
    Mei
    ------------------------------


  • 2.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 09:06 AM
    You will have to look in the client.log file on the Resilient server to see what the problem is.

    Ben

    ------------------------------
    Ben Lurie
    ------------------------------



  • 3.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 10:23 AM
    Hi Ben, thank you for the info. I looked at the client.log on that resilient server. These are the lines around that posting attachment:
    <my host IP> - - [13/May/2020:22:26:16 -0400] "POST /rest/session HTTP/1.1" 200 - 0 [-] http-nio-443-exec-4
    <my host IP> - - [13/May/2020:22:26:17 -0400] "POST /rest/session HTTP/1.1" 200 719 504 [mei_thom@us.ibm.com] http-nio-443-exec-4
    <my host IP> - - [13/May/2020:22:26:57 -0400] "POST /rest/orgs/201/incidents/2136/attachments HTTP/1.1" 200 - 0 [mei_thom@us.ibm.com] http-nio-443-exec-6
    <my host IP> - - [13/May/2020:22:26:57 -0400] "POST /rest/orgs/201/incidents/2136/attachments HTTP/1.1" 500 132 17 [mei_thom@us.ibm.com] http-nio-443-exec-6​

    Not enough details for me to figure out the problem. Is "132" next to "500" meaning the code of the problem?

    Is there way to turn on more detailed level debugging? 

    Please advise. Thanks!

    ------------------------------
    Mei Thom
    ------------------------------



  • 4.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 11:02 AM
    That is the client access log. There should be another log called the client.log with the actual details.

    ------------------------------
    Ben Lurie
    ------------------------------



  • 5.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 11:35 AM
    Hi Ben, sorry about that. I find the client<date>.log in the daily dir. Here is the stack trace about the posting attachment:
    23:24:36.523 [http-nio-443-exec-5] ERROR com.co3.web.rest.Co3ExceptionMapperBase - Mapping exception to REST
    java.lang.NullPointerException: null
    	at com.co3.web.rest.IncidentAttachmentREST.uploadFile(IncidentAttachmentREST.java:187)
    	at com.co3.guice.RESTGuiceModule.lambda$bindTimerInterceptor$2(RESTGuiceModule.java:84)
    	at com.co3.guice.RESTGuiceModule$$Lambda$42.0000000010FCC550.invoke(Unknown Source)
    	at com.co3.guice.RESTGuiceModule.lambda$bindValidateSessionInterceptor$1(RESTGuiceModule.java:73)
    	at com.co3.guice.RESTGuiceModule$$Lambda$41.0000000010FCBA80.invoke(Unknown Source)
    	at com.co3.guice.RESTGuiceModule.lambda$bindTwoFactorAuthInterceptor$0(RESTGuiceModule.java:57)
    	at com.co3.guice.RESTGuiceModule$$Lambda$40.0000000010FCB7C0.invoke(Unknown Source)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
    	at java.lang.reflect.Method.invoke(Method.java:508)
    	at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
    	at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
    	at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
    	at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
    	at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
    	at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
    	at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
    	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
    	at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
    	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
    	at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1409)
    	at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:409)
    	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:558)
    	at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:733)
    	at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
    	at com.google.inject.servlet.ServletDefinition.doServiceImpl(ServletDefinition.java:286)
    	at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:276)
    	at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:181)
    	at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:91)
    	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:85)
    	at com.co3.json.serialize.OutputFormatServletFilter.doFilter(OutputFormatServletFilter.java:132)
    	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
    	at com.co3.web.servlet.Co3ServletFilterBase.doFilterImpl(Co3ServletFilterBase.java:317)
    	at com.co3.web.servlet.Co3ServletFilterBase.lambda$doFilterWithRetry$4(Co3ServletFilterBase.java:272)
    	at com.co3.web.servlet.Co3ServletFilterBase$$Lambda$348.00000000FC075910.run(Unknown Source)
    	at net.jodah.failsafe.Functions$10.call(Functions.java:252)
    	at net.jodah.failsafe.SyncFailsafe.call(SyncFailsafe.java:145)
    	at net.jodah.failsafe.SyncFailsafe.run(SyncFailsafe.java:81)
    	at com.co3.web.servlet.Co3ServletFilterBase.doFilterWithRetry(Co3ServletFilterBase.java:272)
    	at com.co3.web.servlet.Co3ServletFilterBase.doFilter(Co3ServletFilterBase.java:247)
    	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
    	at com.co3.web.filter.HttpFilter.doFilter(HttpFilter.java:37)
    	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
    	at com.co3.web.filter.PreprocessRequestFilter.doFilter(PreprocessRequestFilter.java:41)
    	at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
    	at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:120)
    	at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:135)
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
    	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
    	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)
    	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:494)
    	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)
    	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
    	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:1025)
    	at com.co3.tomcat.valves.RequestAccessLogValve.invoke(RequestAccessLogValve.java:79)
    	at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:689)
    	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
    	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)
    	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1137)
    	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
    	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1780)
    	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1739)
    	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    	at java.lang.Thread.run(Thread.java:812)​

    What would have caused the NullPointerException there?

    Thanks.

    ------------------------------
    Mei Thom
    ------------------------------



  • 6.  RE: Got 500 when posting attachment to incident
    Best Answer

    Posted Fri May 15, 2020 11:51 AM
    It looks like the server can't parse the multipart mime body. It can be tricky to generate that correctly. You can capture a web trace from your browser while you use the Resilient UI and see how it is done. Or you could potentially reuse some code from an app. Maybe like this one: https://github.com/ibmresilient/resilient-community-apps/tree/master/fn_utilities

    Ben

    ------------------------------
    Ben Lurie
    ------------------------------



  • 7.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 12:03 PM
    Hi Ben, thank you for the advice and the pointer. I'll spend some time to look into all those. Will update you what I will hit next.

    Thanks!

    ------------------------------
    Mei Thom
    ------------------------------



  • 8.  RE: Got 500 when posting attachment to incident

    Posted Fri May 15, 2020 11:38 PM
    Hi Ben,

    The root cause is that uploading file expects multipart mime body. Since the file is pdf, I setup content-type=application/pdf. After I removed specifying the content-type and use MultipartEntity for the request body, I got back 200 response code. The pdf file was attached to the incident successfully.

    Thank you for all the info and the help!

    ------------------------------
    Mei Thom
    ------------------------------



  • 9.  RE: Got 500 when posting attachment to incident

    This message was posted by a user wishing to remain anonymous
    Posted Fri February 12, 2021 08:50 AM
    This post was removed


  • 10.  RE: Got 500 when posting attachment to incident

    Posted Fri February 12, 2021 08:50 AM
    Hi Mei,

    I encounterd the sample issue. Would you please share with me the sample code for this? thanks.

    ------------------------------
    SHUANG GAO
    ------------------------------