Remote power cycling

Help
1

i know this is going to be something basic that has to do with my lack of knowledge more than anything else.

i have two pages i can’t get to properly redirect. I have many things working via basic proxy to 127.0.0.1:1234 . i have two pages kicking my butt though.

First on is Shutter (Shutter:Web Interface - den4b Wiki). i have it set to 0.0.0.0 and 9090 in the app. I can get the redirect to show the log in screen and accept my username and password fine. My issue is then that it redirects to my Caddy/www/index.html rather than the shutter interface.on localhost it works great as 127.0.0.1:9090 as im attempting to put in my caddyfile.

The second on is a digital logger power strip. Relative to my server it is located at http://192.168.5.130:6552. It also redirects me to Caddy/www/index.html instead of it’s own interface html.

What stupid thing am i not seeing?

Thanks for any help offered.

2

This confuses me a little - do you mean it’s issuing a redirect with a location of Caddy/www/index.html (as a relative link), i.e. your browser is going to https://example.com/Caddy/www/index.html?

Can you share your Caddyfile with us?

3

See below dropbox link for caddy file and a snippet of file structure. The top three are the two being asked about here as well as me just seeing if i could get a reverse proxy for DD-WRT as well but in looking online it seems that will take some other effort on the router side so i am not terribly concerned about it. It was just there as an initial test.

Thanks very much.

4

Ahh. If I had to take a guess, I’d say the software expects to be served at /, not at /reboot (or /power). Once you log in, it sends you back to the homepage (/), but Caddy hasn’t been told to proxy for requests to /, it thinks it’s meant to serve out of /caddy/www. You’re right in that the backend side will have to be altered for this to work.

5

the problem though is i cannot cahange where shutter or the power supply’s webpage is hosted so i have no idea how i can make caddy look in the proper relative path after the log in.

6

A common issue, I’m afraid. Since you don’t have control over the behaviour of the backend, you will need to configure Caddy to proxy / to it and give it what it wants. Subdomains are often the answer to this problem.

7

im ok with a subdomain if needed. just dont know well enough how to implement it properly. got a good example i can modify to mess with?

8

Using a subdomain is as simple as adding another label block to your Caddyfile.

example.com {
  ...
}
subdomain.example.com {
  ...
}

You just want to put your proxy in the subdomain block, and instead of (e.g.) proxy /reboot you just need proxy /.

9

ok, i may just be over complicating it in my head. ill give it a shot and see what i can manage. Thanks for your help.

Will report back if i get it working.

10

No worries - I can’t download/open your zip file at the moment, but if you want to paste what you end up with here directly I can look over it and try to help. Just open three backticks ``` on a new line, paste the Caddyfile below it, then end with another three backticks ``` on a new line.

```
Your Caddyfile here
```
11 
mydomain.com {

 # tls yourname@email.com        # Email for Let's Encrypt Verification

  startup /caddy/php/php-cgi -b 127.0.0.1:9000 &

  import common.conf

}

####################################################################################
# localhost server block 
####################################################################################

http://localhost {

  import common.conf

}

reboot.mydomain.com {
	proxy / 127.0.0.1:9090 {
		transparent
	}
}

i am basing my caddyfile and common.conf on the ones available on pastebin. If i add reboot.mydomain.com to my caddyfile Caddy will not start, if i comment out those lines it opens fine and shows me the cmd windows with https://mydomain, etc, etc.

12

Do you have the output from this?

Taking a guess here, does reboot.mydomain.com have a DNS record pointing to your server? Caddy might be blocking on failing to acquire the cert from LetsEncrypt.

You’ve structured the label and block perfectly, it shouldn’t be a Caddyfile issue.

13

i went and put in into1&1 but you might be right in that it may take time to update records.

I changed it in my caddy file to be www. Which was in my subdomains list by default but i never did anything with and it came right up. So now i just wait for reboot. and power. to finish registering properly with my service and (fingers and toes crossed) i should be good to go.

Thanks very much for your assistance! That would have been DAYS if i even figured it out at all. I would not have expected the regular proxy vs subdomain to be so different.

Is this the same reason why you have to tell the other services what directory you put them at in the reverse proxy? So they can properly handle this issue?

14

It all comes down to the idea that the URL is meant to indicate the location of the resource, and the URI, as a part of that, is meant to identify which specific resource you want. The hostname part of the URL, by convention, marks which website you want; the URI, in its entirety, marks which webpage.

When you reverse proxy a whole website into its own subfolder, you’re flipping the script a little. You’re using the first part of the URI as something of an extension of the hostname, to tell the web server which website you want. Now, the web server is quite capable of handling this - Caddy is built to be flexible and handle requests differently based on the URI.

Caddy can even omit that URI prefix the client used to tell Caddy which website it wants, so that the website you proxied to via /reboot doesn’t receive a request for “/reboot/index.html” and go “What? I don’t have a /reboot folder…” But in a vacuum, the website thinks it’s got the whole URI, because that’s the assumption the system is based on.

I’m writing a small web app in golang now, and one of the features I’m working on is the ability to set a URL base. You would be surprised at just how many points in the logic you have to thread through this idea of a possible, arbitrary URI prefix. Every time my app issues a redirect, puts an <a href= tag in, it needs to check if the user set a URL base and prepend it to whatever link it’s about to spit out. If I didn’t do that, every link in my app wouldn’t have whatever subfolder I wanted to reverse proxy it into, and all those requests would go to Caddy, and Caddy would have no idea what to do with them. It’s got no way to differentiate which app those requests should go to, except for the URI.

So unless I write my app to accommodate that URI prefix/URL base, right at the core of the program, when you click “home” in my app it’s going to send you to /. And Caddy will happily render the index.html of your root directive, because that’s what you told it to do.

TL;DR: The webui dev never even considered the likelihood that you will reverse proxy it into a subfolder, so they never put the effort in to make it possible.

15

TIL…

thanks for the explaination. I have seen URL and URI but never realized the functional distinction between the two. Something new every day.

16

Should be noted though that terminology changes.

Strictly speaking, the URI is the whole thing (right from the access mechanism, e.g. http://, through to what Caddy refers to as the path, e.g. /foo/bar/index.php). In terms of Caddy, though, the URI is the path+query (the end part after the hostname). So, above when I refer to hostname I mean www.example.com, and by URI I mean /index.php?foo=bar, and by URL I mean the combination of the two, essentially.

17

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