Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Downstream proxy server is online with misconfigured settings #149

Open
mflagler opened this issue May 9, 2024 · 4 comments
Open
Labels
bug Something isn't working

Comments

@mflagler
Copy link

mflagler commented May 9, 2024

Describe the bug
Downstream Inductive Automation Server is working, but uptime monitor shows "Downstream proxy server is online with misconfigured settings"

To Reproduce
Steps to reproduce the behavior:

  1. Point HTTP Proxy to self-hosted Inductive Automation Gateway Server downloaded and installed from here: https://inductiveautomation.com/downloads/archive/8.1.39
  2. Uptime monitor shows misconfiguration

Expected behavior
Uptime monitor shows healthy running server

Screenshots
image

Host Environment (please complete the following information):

  • Arch: Windows x64
  • Device: Windows VM for Testing
  • OS: Windows 11
  • Version: 23H2

Additional context
Attached Wireshark capture with first part doing an edit/save of the HTTP proxy to force it to attempt to re-check the status/uptime. Starting at packet 43 I connected to the same URL (IP and port) as configured directly using Microsoft Edge to show how the browser packets look.

Ignition can be downloaded if wanted for testing by right-clicking the download and doing a save-as to bypass the registration form. A default install with standard edition and doing the initial setup (creating an admin user/password and specifying the ports to use) is all that's needed.

Zoraxy Uptime Monitor Capture.zip

@mflagler mflagler added the bug Something isn't working label May 9, 2024
@tobychui
Copy link
Owner

I have analysis your capture and found out that the capture didn't actually include the uptime monitor request. But anyway, from your screenshot, I think the downstream server is returning a status code in the 5xx range with the misconfigured as a badly chosen error message. I have updated the uptime monitor with better description and UI to reduce users confusion on the uptime status of their servers.

圖片

Will be closing this after next release.

@mflagler
Copy link
Author

mflagler commented May 23, 2024

On my packet capture, packet 24 is the request from Zoraxy and in 25 it gets a 302 Found, but then Zoraxy sends on packet 28 a continuation which then triggers a response on packet 30 of a 400 Bad Request.

I suspect that the server is trying to set a cookie (JSESSIONID) as part of the 302 as seen in packets 11, 15, 19, and 23, but Zoraxy isn't sending the cookies with the redirect. On packet 53 when I do the same in Edge, it gets sent the cookie just the same, but on packet 54 of the redirect, Edge is sending the cookie and then finally gets a 200 OK response.

I think it's essentially getting stuck in a redirect loop because this session cookie isn't being set and it's expecting it to be.

@tobychui
Copy link
Owner

Hi @mflagler thanks for the further explanation!

I guess the packet 24 onward, although it maybe sent from Zoraxy but it is not the uptime checker. The uptime monitor will only report "Misconfigured" when the status code is in the 5xx range under the current implementation (3.0.4)

if (value[value.length - 1].StatusCode >= 500 && value[value.length - 1].StatusCode < 600){

If you are sure the up-time is receiving a 4xx error, then the error code (e.g. Bad request) will be shown on the up-time monitor online status text.

switch(value[value.length - 1].StatusCode){

Lastly, if your server reply 3xx, up-time will still assume it is online, so it clearly your screenshot does not match with what you have in the capture files. That is why I suspect that there are something running & connecting to your server but that "thing" is not the zoraxy up-time monitor checker.

@mflagler
Copy link
Author

mflagler commented May 24, 2024

Here's another packet capture spanning several minutes showing the same result as the original packet capture. There's 2 checks it looks like by the uptime monitor in this capture, and both do a handful of redirect loops before sending a "Continuation" packet that causes the server to return a 400 bad request. I really do think the redirect loop wouldn't happen if cookies were passed that are received by the previous requests and all would be OK.

This is on v3.0.4 and I know the code doesn't say that's the status it will report, but that's how it's showing up on the uptime monitor.

Zoraxy Uptime Monitor Capture 2.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants