Token renewal causes malformed JSON to be delivered with WAS v.9.0.0.10

[Ladderjack]

Using WebSphere Application Server v.9.0.0.10, when the security token managed by proxy.jsp expires or is otherwise deemed invalid, the following happens:

1. The client browser (CLIENT) makes a request to the WebSphere Application Server (APP SERVER) for information required from the GIS REST service endpoint (GIS SERVER).
2. The APP SERVER delivers the request to the GIS SERVER along with a token that is invalid, presumably because of having expired but possibly for other reasons.
3. The GIS SERVER delivers a response (DENIAL RESPONSE) to the APP SERVER indicating that the token is invalid. This response is 61 bytes in length, contains 61 characters and is not passed back to the CLIENT.
4. The APP SERVER delivers a request to the GIS SERVER requesting a new token. This request contains valid credentials.
5. The GIS SERVER delivers a response containing a new valid token and corresponding duration information about that token. This information is not delivered to the CLIENT.
6. The APP SERVER re-delivers the original request from step 2 to the GIS SERVER for the information needed from the GIS SERVER. This request is accompanied with the new valid token delivered in step 5.
7. The GIS SERVER delivers a response containing the originally requested data (GOOD DATA), which is almost always far longer than 61B in length.
8. The APP SERVER attempts to deliver the GOOD DATA by handing the response string to the OutputStream but uses the Content-Length header from the DENIAL RESPONSE in step 3 instead of the most recent response from the GIS SERVER.
9. The APP SERVER detects the mismatch between the Content-Length header and the GOOD DATA, sends the first 61B of the GOOD DATA to the browser and closes the connection to the browser.
10. The CLIENT receives a response from the APP SERVER but instead of being the complete parcel of GOOD DATA, what is delivered is the first 61 characters of the GOOD DATA.

Frankly sir, I don't like it.

[hunterwei]

Experiencing the same issue.

[hunterwei]

I figured out that at step 7, the content-length was changed but the HttpServletResponse was still using the content-length of 61 that for the bad response. Just change response content-length to the correct number right before outputstream write out. Adding below code before buffer.flush() will fix the issue:

      clientResponse.setContentLength(buffer.size());
      buffer.flush();

[Ladderjack]

Oh yeah, we fixed that in the proxy piece eight months ago. Just lie to the code about the buffer length. The code is marginally less secure but who cares?

J

On Wed, Sep 2, 2020, 5:32 PM Hunter Wei notifications@github.com wrote:

I figured out that at step 7, the content-length was changed but the HttpServletResponse was still using the content-length of 61 that for the bad response. Just change response content-length to the correct number right before outputstream write out. Adding below code before buffer.flush() will fix the issue:

  clientResponse.setContentLength(buffer.size());
  buffer.flush();

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Esri/resource-proxy/issues/528#issuecomment-686063023, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSKXNEKWDIFQE6BGWSCLC3SD3BXZANCNFSM4ISE5URA .

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you need additional assistance please contact Esri Technical Support. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you need additional assistance please contact Esri Technical Support.