OpenSprinkler Reverse Proxy Help

Help
1

Hi All,

I have Caddy setup and working correctly with Sonarr, Radarr, etc. however I am having issues with my irrigation controllers. I have 3 of them on different ips, and ports but when using domain.com/homeos, I am only able to log into the first one then even when I change from the first one to the second one domain.com/shopos it still loads the first controller I logged into. Not sure if it is the sprinkler software or Caddy configuration as if I just use the remote ip + port # it works fine.

I am seeing this in the log file.
192.168.1.1 - [24/Mar/2017:07:39:07 -0700] “GET /ja?pw=a6d82bced638de3def1e9bbb4983225c&_=1490366300012 HTTP/2.0” 200 860

Wondering how I can just pass 192.168.1.118:8118 or remote ip:8118 to the irrigation controller.

My Caddy File
proxy /shopos 192.168.1.118:8118 {
transparent
without /shopos
}
proxy /homeos 192.168.1.119:8119 {
transparent
without /homeos
}
proxy /fieldos 192.168.1.120:8120 {
transparent
without /fieldos

Thanks,

2

What happens if you remove the without lines?

3

I get this message {“result”:32}

4

Sorry that means nothing to me. And I don’t know anything about “OpenSprinkler”

So you Caddy proxying to 3 different “controller” daemons? Are you starting the controllers with a configuration that tells them to listen on 8118, 8119, 8120 each respectively?

The proxy directive with transparent will forward the request with some additional headers. You could try without transparent.

You should also try fully clearing your browser cache before accessing via Caddy. Perhaps a cookie or something is being set wrong.

Best of luck

5

Can you provide your full unedited Caddyfile?

6

Sure here it is. I have also tried to clear out my browser cache several times. I also tried without transparent and get the same issue of not being able to hit the other controllers.

www.domain.com, http://domain.com {
root c:\webroot
gzip
log c:\Caddy\access.log {
Rotate {
size 10 # Rotate after 10 MB
age 14 # Keep rotated files for 14 days
keep 10 # Keep at most 10 log files
}
}
errors c:\Caddy\caddyerror.log

proxy /sonarr 192.168.1.116:8989 {
transparent
}
proxy /sabnzbd 192.168.1.116:8080 {
transparent
}
proxy /plexpy 192.168.1.116:8086 {
transparent
}
proxy /ohm 192.168.1.116:8888 {
transparent
}
proxy /radarr 192.168.1.116:7878 {
transparent
}
proxy /shopos 192.168.1.118:8118 {
without /shopos
}
proxy /homeos 192.168.1.119:8119 {
without /homeos
}
proxy /fieldos 192.168.1.120:8120 {
without /fieldos
}
proxy /request 192.168.1.116:3579 {
transparent
}
proxy /hydra 192.168.1.116:5075 {
transparent
}
}

7

In this caddyfile you seem to have either transparent or without but not both? Is this correct?

8

I did try transparent with it but got the same results of only being able to see the first proxy I hit /homeos for example. Only when I do not have “without” do I get that “result” 32.

9

In looking at Chrome Developer tools I am seeing this for the header

Request URL:https://www.domain.com/homeos
Request Method:GET
Status Code:200
Remote Address:xxx.xxx.xxx.xxx:443

I tried this for the caddy file, thinking that if I could change the port on the remote address it would work, am I using this correctly? I trying to see what it actually sends.

proxy /shopos 192.168.1.118:8118 {
header_upstream Host {host}
header_upstream X-Real-IP {remote}{port}
header_upstream X-Forwarded-For {remote}{port}
without /shopos
}
proxy /homeos 192.168.1.119:8119 {
header_upstream Host {host}
header_upstream X-Real-IP {remote}{port}
header_upstream X-Forwarded-For {remote}{port}
without /homeos
}

10

You are technically using it correctly, but those headers don’t usually contain port information, and it’s largely irrelevant to the program anyway - the port you connect to it on is the only port that matters. The likelihood of the program being designed to care about the port in the proxy headers is slim.

A quick google indicates that the {"result":32} is some kind of API response from OpenSprinkler. That makes it look like Caddy’s hitting the right spot, but the upstream is not responding how you are expecting it to.

If you curl 192.168.1.118:8118 (and on the other ports), do you receive the expected response?

11

I get this on all 3, not the {“result”:32}. I am on Windows and downloaded and installed curl. I am assuming I am getting the correct response.

C:\Program Files\cURL\bin>curl.exe 192.168.1.120:8120
<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1.0,minimum-scale=1.0,user-scalable=no">
</head>
<body>
<script>var ver=217,ipas=0;</script>
<script src="https://ui.opensprinkler.com/js/home.js"></script>
</body>
</html>
13

Huh, I guess the whole thing gets rendered by JS.

Taking another look at the api documentation, a result of 32 is a “page not found” error. Might have something to do with the specific path being requested by the proxy.

Try something as simple as possible, to narrow down potential configuration issues:

homeos.domain.com {
    proxy / 192.168.1.119:9119
}

Don’t bother with transparent or without for now.

14

I think this might be a cross-origin CORS issue as the JS script is loaded from a different domain. You should use the cors plugin or manually set the Access-Control-Allow-Origin headers appropriately.

I also noticed int this thread (Mobile app "unable to connect" through SSL reverse proxy (Apache) | OpenSprinkler) that the {result: 32} is seen when the /js gets an extra slash injected somehow and becomes /js/, although it’s not clear why. Again, I suspect the JavaScript is in error and may be related to CORs.

1 Like
15

Thanks all for the help. I added CORS and was able to get to the OpenSprinkler but would not take the password. It works when I use the port # at the end of domain.com:8119. I am fine with this currently as in the OpenSprinkler App it works as it should and once I have it set up for the season I rarely make changes.

I do like using Caddy and will continue to do so as it works with my other projects.

1 Like
16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.