[Question] Reverse proxying to a different location

[Omoeba]

I use nginx to redirect https://domain.com/adguard to https://domain.com:[adguard listen port]. The new update causes adguard to give a 302 redirect to https://domain.com/login.html, which obviously fails since the actual login url is https://domain.com/adguard/login.html.

[ameshkov]

Hm, this might be tricky to fix. We'll see, it might be necessary to add an optional config field for this kind of setup.

[Omoeba]

@ameshkov The logout is also broken

[szolin]

AGH works correctly and knows nothing (and shouldn't know) about any additional HTTP configuration that users set up. Isn't there a possibility to manage HTTP redirections in nginx configuration? You should rewrite Location HTTP header's value appropriately.

It would be very strange to add an additional configuration to AGH for this.

[ameshkov]

Yeah, @szolin, you're right.

It is possible to handle this on the nginx's side:
https://stackoverflow.com/questions/19568452/modifying-a-location-header-with-nginx-proxy-pass

[Omoeba]

I have added proxy_redirect /login.html /adguard/login.html; to my nginx configuration and it fixed the login issue; but after clicking "Sign in", I am redirected to domain.com instead of domain.com/adguard/, adding proxy_redirect / /adguard/ did not fix the issue. Also, proxy_redirect /control/logout /adguard/control/logout did not fix logging out.

[ameshkov]

Marked this issue as "help wanted", maybe someone more experienced with nginx than I am, chimes in and helps.

[adriancleung]

I have the same issue.
@szolin
I think there should be some support for reverse proxy as not everyone wants to expose external ports to the internet. Yah it may be strange to add this to the configuration file but from a design and user perspective, this can be a requirement for some end user who needs such customization and programmability. I know there’s the “Inventor’s Dilemma” but I feel like doing the bare minimum or satisfying the “it works” is not sufficient. From a software design process, I believe your statement about it being “strange to add an additional configuration to AGH“ is invalid. BUT, I don’t know much of HTTP configurations and software practices so I’m open to your opinion.

[szolin]

AGH doesn't need to know anything about your redirections. This is the task of your proxy web server.
Try this nginx configuration:

location ~ ^/adguard(.*)$ {
    rewrite /adguard/(.*) /$1 break;
    proxy_pass http://$adg_addr:3000;
}

It's a rewrite rule that strips /adguard from URLs.

[Omoeba]

@szolin doesn't work

[szolin]

What exactly doesn't work? Can you show HTTP requests, responses (with headers)?

[Omoeba]

@szolin same thing as my original issue

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[redrathnure]

Would join this discussion. I had the same issues trying to rewrite from ADH http://localhost:8080 to http://somehost/adguard/.
I use ADH v0.100.6 on linux sererver and following nginx config:

  proxy_cookie_path / /adguard/;
  proxy_redirect /login.html /adguard/login.html;
  proxy_pass http://127.0.0.1:8082/;
}

There are few points to be should be handled during changing WEB path:

1. Static content URLs (links to CSS, JS and image files)
2. Cookies. Basically it's about Path field for Set-Cookie header)
3. Redirects (if there any). Means Location header for 301 response
4. URL for AJAX/XHR requests, Form submits (if there any) and other links between pages.

Looks like relative URLs(no leading /) are used for CSS, JS and images:

  <link href="main.13dcbd52d77591431c082dfb6f5b7d30.css" rel="stylesheet">
</head>

so no problems so far (at least till somebody decide to add / at start)

Cookies Path may be corrected by nginx (see proxy_cookie_path directive). Redirects may be solved by nginx (see proxy_redirect directive). XHR calls (API calls for control/xxx URLs) also work correctly because use relative URLs (without leading /).

Most tricky part is some URLs, e.g. HTTP GET / after success login and handler for logout button. These URLs are "Root-relative URL" (starts from /) and they are hardcoded in JS. Nginx cannot handle this cases correctly (maybe because parsing/rewriting minimized JS does not looks like trivial task).

There are few ideas:

1. Make it possible to configure ADH for certain WEB path. E.g. during installation we should specify port and path for WEB UI (e.g. 8080 + /adguard). Then all links (cookies path, css/js and links) may use this path as preffix. Something like /adguard/main.13.css, /adguard/favicon.png, /adguard/login.html, /adguard/control/ etc
   Prons: "Root-relative" URLs would be more match easy to handle by reverse proxy. Nginx/Apache configuration would be trivials (let's call it "Admin and devops freandly configuration" and no need to parse and rewrite response content on the fly (which may be good from performance point of view).
   Cons: seems need some code adjustments

2. Using relative URLs everywhere. Even for login/logout handlers.
   Prons: looks like easy solution (just check login/logout links in JS code)
   Cons: not sure that relative URLs are the best choice... however should be OK for single page app

PS: "ADH behind reverse proxy" looks like a quiet typical use case. Maybe it has sense to add this info (including nginx config sniplets) into documentation.

[ameshkov]

@redrathnure thank you for the very nice explanation!

Tbh, I like the second option more. It's always better to avoid adding new settings when it's possible:)

I've filed a new issue about this, planned on v0.101: #1300