Core: Configurable WebRoot

Created on 27 Dec 2015 · 28Comments · Source: home-assistant/core

I don't see it anywhere in the docs and it looks like (based on const.py) that the webroot is not configurable. This makes it difficult to run behind a reverse proxy (like nginx) to add SSL without having to do a bunch of fancy trickery.

As an example, given this nginx config:

location  /home/things {
        proxy_ignore_client_abort on;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Server $http_host;
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass   http://homeassistant.host.name:8123;
}

Which is pretty standard, results in a bunch of broken things because the URLs for all of the assets are absolute.

Even adding:

rewrite ^/home/things/(.*) /$1 break;

or some trickery:

sub_filter '/static/' '/home/things/static/';
sub_filter '/api/' '/home/things/api/';
sub_filter_once off;
sub_filter_types *;

Still results in broken things. If there is a better nginx config let me know but I think the real solution is just to have a configurable web_root.

enhancement

Source

wazoo

👍1

Most helpful comment

+1 from me. I'd like to run HA under https://my.domain/home and can't really figure it out how to do this.

simonszu on 5 Sep 2016

👍17

All 28 comments

Can you see if using the base tag in the index fixes re-rooting the web application?

I ended up running it on a subdomain instead of a sub-directory on my nginx configuration. Then using CloudFlare to handle signed SSL.

For /home/things it would be

<head>
  <base href="https://homeassistant.host.name/home/things" />
</head>

I believe that's right

nevercast on 28 Dec 2015

It is currently not possible to configure it. Among other things the API root is defined here

balloob on 28 Dec 2015

Okay, how do I turn this into a feature request then? Using a subdomain is alright but that means I would have to buy two SSL certificates. I think that being able to configure it to have the API just mount relative to the configured webroot by default would be fine.

wazoo on 29 Dec 2015

@wazoo Have you considered using Lets encrypt? It's fairly easy to setup with hass.

Landrash on 30 Dec 2015

Yeah, I mean that is possible too. I like using sub directories for the 'family acceptance factor' because then I can tell them to go to /home for a dashboard (hass in this case) or

wazoo on 2 Jan 2016

I would also very much like this feature. I could probably work on it from the python side, but I don't really speak js.

Cadair on 4 Jan 2016

Off Topic, but @wazoo
Use https://letsencrypt.org/ or even CloudFlare

Then you get free SSL and can have as many subdomains as you wish.

nevercast on 5 Jan 2016

Look, I realize that I can use letsencrypt or buy another certificate or use cloudflare or whatever (this isn't my first rodeo with a web service) but that is not the point of this request. I don't /want/ to use a subdomain or anything other than a directory location, period. I do appreciate the help and suggestions but it says in earlier comments that I don't want to use a different sub domain for various reasons.

wazoo on 5 Jan 2016

I didn't notice that both had already been suggested, one of them by me already. A 3am comment with neglect to look at the other comments.

I'm not familiar with python but I'm familiar with JS. I'll look at the client side.

nevercast on 7 Jan 2016

Hah fair enough, I do that too. Sorry if I came off overly snarky, it was after a long day for me as well. I don't know Python that well but I was going to tinker with it a bit.

wazoo on 7 Jan 2016

Hello. I tried to implement this, but ultimately failed. The Python bits were straightforward enough to change, but the whole reactive nuclear polymer flux babel frontend proved too much for me :-)

You can find the backend changes for serving everything under a configurable webroot here: https://github.com/gvalkov/home-assistant/commit/d35e3a2cadbf6cbbf8106a548720aab8eb5bf0a6. I sincerely hope that someone well versed in modern web development can help with this one.

gvalkov on 8 Feb 2016

One of the challenges when it comes to the frontend is that the url that is used for serving the web app can be different levels deep: /, /states, /map, /states/group.upstairs

balloob on 9 Feb 2016

One of the things I was thinking was to set the basepath in the router like this example in Page.js: https://visionmedia.github.io/page.js/#pagebasepath

This could be done by having the router (or just the relevant part of it) served as a dynamic page (vs a static js file) that way it would be possible to inject the configured path from hass itself. I have done this with other projects but I don't really know JS well enough to test it here, it doesn't look like you are using Page.js but I am not exactly sure which repo that would be in.

Just a thought!

wazoo on 12 Feb 2016

I was thinking of setting a global window.webroot in index.html.template or getting it from the value of the base tag.

gvalkov on 14 Feb 2016

Closing this issue as feature requests should be posted in the forum.

balloob on 9 Apr 2016

Is there a followup post in the forums?

I believe this post predates the forums, so a migration trail would be better fitting than just closing the thread. I'm worried that information about requests would be lost if we're expected to create new threads without being required to link to the Github-equivalent thread. Before closing other old posts, would you be able to open a short post in the forums with a link to the original? Thanks!

kodek on 9 Apr 2016

I don't have time for that. If the feature is important enough to still be
requested, make a post and link to the GitHub issue for previous discussion.

On Sat, Apr 9, 2016 at 10:58 AM, kodek [email protected] wrote:

Is there a followup post in the forums?

I believe this post predates the forums, so a migration trail would be
better fitting than just closing the thread. I'm worried that information
about requests would be lost if we're expected to create new threads
without being required to link to the Github-equivalent thread. Before
closing other old posts, would you be able to open a short post in the
forums with a link to the original? Thanks!

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub
https://github.com/balloob/home-assistant/issues/805#issuecomment-207822853

PaulusSchoutsen.nl
It's nice to be important but it's more important to be nice.

balloob on 10 Apr 2016

Followup.

kodek on 10 Apr 2016

@nevercast can you share how you managed to get hass running under a sub-domain?

JakeCowton on 21 Apr 2016

@JakeCowton Sure, I'm using nginx on my RPI as a reverse proxy.
CloudFlare handles my SSL and caching of the subdomain and redirects to my home using DuckDNS, this connection is also over SSL but with a self signed certificate.

nginx on the RPI receives the connection and proxies it to localhost on port 8080. So Home Assistant still runs at root path, but on a different port; nginx handles the forwarding, nginx also handles the SSL, but as said, that side is self signed, hence the use of CloudFlare to middle-man the exchange.

Hope that's enough information, @ me if you need more info. I can SSH and bring up the nginx configuration if necessary.

nevercast on 23 Apr 2016

In the next release (or maybe the one after) we hope to be pushing a rewrite of the HTTP component, based on a real WSGI stack. It will make stuff like this a lot easier from within HA.