refresh not working via apache proxy

[mboeru]

I have setup the web interface of supervisor to run on 127.0.0.1:9001, and I have setup a reverse proxy in apache so I can load the webpage via apache.
the page would be accesible at http://my.domain.ext/supervisor/

Now when I try to refresh the web page via the refresh button I get sent to

http://my.domain.ext/supervisor/index.html?action=refresh

which in turn redirects me to

http://127.0.0.1:9001/?message=Page%20refreshed%20at%20Mon%20Jul%20%201%2016%3A46%3A22%202013

which of course it does not work

The same thing happens when I press stop all, or stop/start/restart on each service.

[fengsi]

Am looking at the same issue. Thought it's due to HTTPS redirect (the magic "X-Forwarded-Proto" / "X-Forwarded-Protocol" header) but since you are using HTTP, this could be related to the rewrite rule only.

Before diving into supervisor source code, will check on Nginx first. If it works well then Apache should work too as long as it's configured correctly.

[mboeru]

This is the apache config I currently use:

<Location /supervisor/>
    ProxyPass http://127.0.0.1:9001/
    ProxyPassReverse http://127.0.0.1:9001/
    AuthName "Secure Area"
    AuthType Basic
    AuthUserFile /path/to/.htpasswdsupervisord
    require valid-user
</Location>

I am using
supervisord -v
3.0b2

Let me know if I can provide more info

[fengsi]

Tried Nginx but didn't help. Looks like a bug but need to debug.

BTW, supervisor has another issue due to similar reason with HTTPS ==> HTTP insecure redirect due to lack of considering of reverse proxy scenario (HTTP for supervisor behind HTTPS reverse proxy). In the source code a strange SERVER_PORT_SECURE header seems to be checked but the comment says "XXX this will currently never be true". A typical way would be to check either "X-Forwarded-Proto" or "X-Forwarded-Protocol" header.

I'll see if those two bugs could be fixed without ugly hacking...

[guettli]

I have the same issue. I run supervisor with this apache config:

    ProxyPass /supervisor/ http://127.0.0.1:9001/
    ProxyPassReverse /supervisor/ http://127.0.0.1:9001/

I can't access the server via port 9001, only https (443) allowed. That's why I need to access supervisor via https://server/... (without ":portnumber").

[tlatorre-uchicago]

One way to hack it in nginx:

    location /supervisor {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host/supervisor/index.html;
      proxy_redirect off;
      rewrite ^/supervisor(.*)$ /$1 break;
      proxy_pass http://supervisor;
    }

[pataquets]

Also stumbled on this one. If I set a 'stud' or stunnel SSL/TLS terminator on top of Supervisor HTTP UI, clicking on any button redirects to the non-HTTPS page URL and breaks navigation.
Any pointer on where can be the culprit?

[Paul424]

I've had the same issue; the proxy_redirect directive just would not match the location i expect from supervisord (i expect localhost:9111) but found only matches on http:// (so far...).

I got it solved by changing the host:

proxy_set_header Host localhost;

It looks like there is a bug when use supervisord web interface behind nginx proxy with HTTPS scheme. The redirection after click on buttons goes to HTTP urls instead of HTTPS in spite of proxy_set_header X-Forwarded-Proto $scheme; used in nginx config. Could it be fixed?

[wooyek]

This is because actual sheme is ignored:

supervisor/supervisor/http.py

Line 308 in 91d909c

if (environ.get('HTTPS') in ('on', 'ON') or

and cgi_environment will never set HTTPS or SERVER_PORT_SECURE headers. Any header not included explicitly will get a HTTP_ prefix:

supervisor/supervisor/http.py

Line 297 in 91d909c

key='HTTP_%s' % ("_".join(key.split( "-"))).upper()

[mnaberez]

Closing as duplicate of #29 which describes the same problem and is also linked from many related issues. It should be resolved when #593 or similar is merged.