[Galene] Behind reverse proxy, not at the root

[Galene] Behind reverse proxy, not at the root

[Francis Bolduc]

Hi,

I'm currently running Galene behind a reverse proxy (that handles TLS)
alongside other web applications on the same host.

Each application has its own path. For example, I have a file server
located at https://myhost.com/files and a streaming service at
https://myhost.com/stream.

Each application has some configuration option to tell it that they
are not located at the root, but rather under some path like /files or
/stream.

However, I've not found how to do that with Galene. Is there an option
to this that I missed?

Regards,
Francis

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> Each application has its own path. For example, I have a file server
> located at https://myhost.com/files and a streaming service at
> https://myhost.com/stream.
> 
> Each application has some configuration option to tell it that they
> are not located at the root, but rather under some path like /files or
> /stream.
> 
> However, I've not found how to do that with Galene. Is there an option
> to this that I missed?

No, it's not currently supported.  It wouldn't be too difficult to do, as
usual it's testing that's a pain.  (Galene has a fairly extensive set of
units tests for low-level functionality, but there are no high-level tests
of the server as a whole, so I need to test manually with each release.
So the more configuration options we add, the more testing I need to do.)

I'll think it over, but no promises.

(Off topic, but are you aware that by doing that you defeat sandboxing?
HTML5 performs sandboxing on a per-origin basis, not a per-subtree basis,
so when multiple applications are running on the same domain, a security
flaw in just one of the applications will allow exploitation of all of
them.  For example, an XSS vulnerability in your files application will
allow an attacker to exfiltrate Galene's passwords.  The more secure
configuration is to use a different hostname for each application,
files.example.org, stream.example.org, etc.)


-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

> No, it's not currently supported.  It wouldn't be too difficult to do, as
> usual it's testing that's a pain.  (Galene has a fairly extensive set of
> units tests for low-level functionality, but there are no high-level tests
> of the server as a whole, so I need to test manually with each release.
> So the more configuration options we add, the more testing I need to do.)
>
> I'll think it over, but no promises.

Thanks. I'll be happy to run some testing on my side if you have a
preliminary branch.


> (Off topic, but are you aware that by doing that you defeat sandboxing?
> HTML5 performs sandboxing on a per-origin basis, not a per-subtree basis,
> so when multiple applications are running on the same domain, a security
> flaw in just one of the applications will allow exploitation of all of
> them.  For example, an XSS vulnerability in your files application will
> allow an attacker to exfiltrate Galene's passwords.  The more secure
> configuration is to use a different hostname for each application,
> files.example.org, stream.example.org, etc.)

Yes, I am aware. But I don't have control over the DNS and can't add
subdomains at will, unfortunately. :(

And, in my case, it's a private server that isn't hosting anything of
value. So we're comfortable with the risk.

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> Each application has its own path. For example, I have a file server
> located at https://myhost.com/files and a streaming service at
> https://myhost.com/stream.

Done.  With current master (2024-02-24), you should be able to set

  "proxyURL": "https://myhost.com/galene"

or even just

  "proxyURL": "/galene"

There are unit tests, but I haven't actually tried setting up a reverse
proxy, and I may have missed something, so please test.

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

> Done.  With current master (2024-02-24), you should be able to set
>
>   "proxyURL": "https://myhost.com/galene"
>
> or even just
>
>   "proxyURL": "/galene"
>
> There are unit tests, but I haven't actually tried setting up a reverse
> proxy, and I may have missed something, so please test.
>
> -- Juliusz

Great!

I will try it this weekend.

Regards,
Francis

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

I just tried using the suggested configuration:

> "proxyURL": "/foo"

But when I go to that URL, I get the following message:

  Page not found!
  We can't find the page you're looking for.
  Back to home

Version used: 0d7d54751a0abc7f911da77037fb4602c34caeda

Regards,
Francis

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> I just tried using the suggested configuration:
> 
>> "proxyURL": "/foo"
> 
> But when I go to that URL, I get the following message:
> 
>   Page not found!
>   We can't find the page you're looking for.
>   Back to home

Is your proxy rewriting the paths?  Or is it just gluing multiple sites
together?

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

> > I just tried using the suggested configuration:
> >
> >> "proxyURL": "/foo"
> >
> > But when I go to that URL, I get the following message:
> >
> >   Page not found!
> >   We can't find the page you're looking for.
> >   Back to home
>
> Is your proxy rewriting the paths?  Or is it just gluing multiple sites
> together?

The latter. I use haproxy with a frontend config that forwards the
HTTP requests to a backend server based on path rules. Here is an
example config:

    frontend https
     bind *:443 ssl crt /etc/haproxy/selfsigned.pem crt
/etc/haproxy/certs.d alpn h2,http/1.1
     mode http
     acl is_path_galene path_beg -i /foo
     use_backend galene if is_path_galene

    backend galene
     mode http
     server srv_galene 127.0.0.1:43210

And I launch galene with the following flag:
    --http=127.0.0.1:43210

Regards,
Francis

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

>> Is your proxy rewriting the paths?  Or is it just gluing multiple sites
>> together?

> The latter. I use haproxy with a frontend config that forwards the
> HTTP requests to a backend server based on path rules. Here is an
> example config:

>     frontend https
>      bind *:443 ssl crt /etc/haproxy/selfsigned.pem crt
> /etc/haproxy/certs.d alpn h2,http/1.1
>      mode http
>      acl is_path_galene path_beg -i /foo
>      use_backend galene if is_path_galene
> 
>     backend galene
>      mode http
>      server srv_galene 127.0.0.1:43210

What happens if you add

    http-request set-path "%[path,regsub(^/foo/,/)]" if is_path_galene

?

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

I did a bit more debugging.

Assuming the following galene configuration:

    "proxyURL": "/foo"

Assuming galene expects paths at the root when doing HTTP GET requests:
   GET /$$$
and not:
   GET /foo/$$$

Using the following haproxy backend config:
    http-request replace-uri ([^/:]*://[^/]*/foo[/]?)?(.*) /\2
That replaces "http://127.0.0.1/foo/bar" by "/bar".

Causes browser queries resulting in 404:
    http://127.0.0.1/mainpage.css
    http://127.0.0.1/galene.css
    http://127.0.0.1/mainpage.js
    http://127.0.0.1/common.css

HTML is rendered bare-bones and without style. I assume this is
because the path to the stylesheet in the root HTML page is missing
the "/foo" proxyURL prefix.

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> Using the following haproxy backend config:
>     http-request replace-uri ([^/:]*://[^/]*/foo[/]?)?(.*) /\2
> That replaces "http://127.0.0.1/foo/bar" by "/bar".
> 
> Causes browser queries resulting in 404:
>     http://127.0.0.1/mainpage.css
>     http://127.0.0.1/galene.css
>     http://127.0.0.1/mainpage.js
>     http://127.0.0.1/common.css

I'm unable to reproduce your issue.  I've set the config.json to:

    {
        "proxyURL": "/foo"
    }

I've then run Galene as

    go run galene.go -insecure

and I can access the above files with no issue:

    $ curl -I http://127.0.0.1:8443/mainpage.css
    HTTP/1.1 200 OK
    ...

Is there something else that you've tweaked in your configuration?

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

I expected the URL to be:
    http://127.0.0.1:8443/foo/mainpage.css
And not:
    http://127.0.0.1:8443/mainpage.css

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> I expected the URL to be:
>     http://127.0.0.1:8443/foo/mainpage.css
> And not:
>     http://127.0.0.1:8443/mainpage.css

I understand that's what you expected.  But that's not what the "proxyURL"
option does.

The "proxyURL" option informs Galene that URLs visible to the client are
different from the URLs visible to Galene.  It makes it possible to run
Galene behind a reverse proxy that rewrites request, for exemple by
remapping HTTPS to HTTP, by remapping an external host to localhost, or,
in your case, by remapping URLs.

Galene will not do any URL rewriting, that's the job of the reverse proxy.
Of course, I could implement URL rewriting in Galene itself, but since
reverse proxies already know how to do rewriting, I'd spending time doing
work that has already been done (probably much better and in a more
flexible manner) by reverse proxy developers.

So please configure your reverse proxy to rewrite URLs before they hit
Galene, or else explain to me why it's better to rewrite URLs in Galene
rather than in the reverse proxy.

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Francis Bolduc]

If you recall my original email, I did not ask for URL rewriting.

What I would like to do is to host Galene in a directory, so that it
would look like this from the client side:
    GET https://myhost.com/foo/index.html
    GET https://myhost.com/foo/mainpage.css
    GET https://myhost.com/foo/galene.css
    GET https://myhost.com/foo/mainpage.js
    GET https://myhost.com/foo/common.css

As you suggested, I did configure my reverse proxy so that Galene gets
modified HTTP GET requests with the "/foo/" directory removed. I
thought that was weird, as the other applications I use on the same
host such as filebrowser.org and forge-vtt.com do not require such
fiddling with the HTTP requests. But I gave it a try anyway.

And that did not work because Galene seems to return the same content
without any modification to any path no matter what I configure in the
proxyURL field.

I don't know of any reverse proxy that can inspect the backend HTML
outputted by Galene, rewrite the paths to add the "/foo/" directory,
and then send the modified HTML to the client from the frontend. And I
doubt this is even possible considering Javascript is involved.

Or am I missing something?

Regards,
Francis

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

> And that did not work because Galene seems to return the same content
> without any modification to any path no matter what I configure in the
> proxyURL field.

Ah, right.  What I've implemented is rewriting of dynamically-generated
links, but there's also the static links in the provided HTML files.

So somebody needs to go through all the HTML files in "static/", and
replace all absolute links with relative ones.  If you do that, I'll be
glad to apply your patch upstream.

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

>> And that did not work because Galene seems to return the same content
>> without any modification to any path no matter what I configure in the
>> proxyURL field.

> Ah, right.  What I've implemented is rewriting of dynamically-generated
> links, but there's also the static links in the provided HTML files.

I've looked into the problem, and it's not obvious how to allow that
without requiring users to manually edit the HTML pages.  The problem is
that Galene's HTML files may appear at different levels in the hierarchy;
hence, they cannot use relative links to the CSS and JS files.

The obvious solution would be to make these pages dynamically generated,
but that in turn would make it difficult for people to customise them as
they wish.  Since I think that allowing easy customisation is more
important than making Galene easy to use with reverse proxies, I haven't
done that.

Please let me know if you see a good solution.

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Dianne Skoll]

On Sun, 03 Mar 2024 16:20:36 +0100
Juliusz Chroboczek <jch@irif.fr> wrote:

> The obvious solution would be to make these pages dynamically
> generated, but that in turn would make it difficult for people to
> customise them as they wish.  Since I think that allowing easy
> customisation is more important than making Galene easy to use with
> reverse proxies, I haven't done that.

I think if you replace all links of the form:

   href="/whatever/the/link/is"

with:

   href="%WEBROOT%/whatever/the/link/is"

it wouldn't hurt customizability very much.  Of course, you then have
the cost of running all the pages through a filter to replace %WEBROOT%
with either the empty string for the default case or the prefix if Galene
is not installed under /.  Maybe it's not worth it.  Setting up virtual hosts
is easy and LetsEncrypt gives out free wildcard certs, so IMO it's better
to use a dedicated hostname for Galene.

Regards,

Dianne.

[Galene] Re: Behind reverse proxy, not at the root

[Juliusz Chroboczek]

>> The obvious solution would be to make these pages dynamically
>> generated, but that in turn would make it difficult for people to
>> customise them as they wish.  Since I think that allowing easy
>> customisation is more important than making Galene easy to use with
>> reverse proxies, I haven't done that.

> I think if you replace all links of the form:
> 
>    href="/whatever/the/link/is"
> 
> with:
> 
>    href="%WEBROOT%/whatever/the/link/is"

Uh-huh.  Or I could use Go's templating system to rewrite the pages.

> Maybe it's not worth it.

I really don't know.  On the one hand, it's a matter of running a sed
script over the HTML files, and I'd expect anyone who's able to set up
a reverse proxy to be able to do a global search and replace.  On the
other hand, some people have to live in restricted environments (they
don't control their DNS), and I'd like to make their lives as easy as
possible.

So I really don't know.

-- Juliusz

[Galene] Re: Behind reverse proxy, not at the root

[Dirk-Willem van Gulik]

On 3 Mar 2024, at 16:30, Dianne Skoll via Galene <galene@lists.galene.org> wrote:
> On Sun, 03 Mar 2024 16:20:36 +0100 Juliusz Chroboczek <jch@irif.fr> wrote:
> 
>> The obvious solution would be to make these pages dynamically
>> generated, but that in turn would make it difficult for people to
>> customise them as they wish.  Since I think that allowing easy
>> customisation is more important than making Galene easy to use with
>> reverse proxies, I haven't done that.
...
>  href="%WEBROOT%/whatever/the/link/is”

Alternatively - given that, if one drops the leading ‘/‘ on src/href all these links end up being, I think, of the style

	https://galene.domain.com/PREFIX/group/<foo>/….

Such as for the group “Ww":

	https://galene.domain.com/PREFIX/group/Ww/galene.js
	https://galene.domain.com/PREFIX/group/Ww/external/fontawesome/css/regular.min.css

Mapped in general from

	https://galene.domain.com/PREFIX(.*)
to

	http://127.0.0.1:8888/$1;

Where 127.0.0.1:8888 is what is the ' -http 127.0.0.1:8888 ‘ arg of Galene says. So we just strip ‘PREFIX’ here. With only a few exemptions from that rule for:

	https://galene.domain.com/PREFIX/ws (websocket only)
	https://galene.domain.com/PREFIX/group/Ww/ (as is)
	https://galene.domain.com/PREFIX/group/Ww/.status.json

That need to be mapped routed to their original places. This works well enough for me against Freebsd-ports and an apache/nginx (TLS stripping, reverse proxy) to Jail (galena, http) setting. And with below ‘just strip out the /‘ approach. I think it only breaks in one place — at the 404 not found that wants to send you to the root.

That may be an easy thing to add to galene perhaps.

With kind regards,

Dw.


diff -r galene.old/404.html galene/404.html
7,8c7,8
<     <link rel="stylesheet" href="/common.css">
<     <link rel="stylesheet" type="text/css" href="/404.css"/>
---
>    <link rel="stylesheet" href="common.css">
>    <link rel="stylesheet" type="text/css" href="404.css"/>
10,12c10,12
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/fontawesome.min.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/solid.min.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/regular.min.css"/>
---
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/fontawesome.min.css"/>
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/solid.min.css"/>
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/regular.min.css"/>
25c25
<         <a href="/" class="home-link">Back to home</a>
---
>        <!-- a href="/" class="home-link">Back to home</a -->
diff -r galene.old/galene.html galene/galene.html
8,9c8,9
<     <link rel="stylesheet" type="text/css" href="/common.css"/>
<     <link rel="stylesheet" type="text/css" href="/galene.css"/>
---
>    <link rel="stylesheet" type="text/css" href="common.css"/>
>    <link rel="stylesheet" type="text/css" href="galene.css"/>
11,15c11,15
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/fontawesome.min.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/solid.min.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/fontawesome/css/regular.min.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/toastify/toastify.css"/>
<     <link rel="stylesheet" type="text/css" href="/external/contextual/contextual.css"/>
---
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/fontawesome.min.css"/>
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/solid.min.css"/>
>    <link rel="stylesheet" type="text/css" href="external/fontawesome/css/regular.min.css"/>
>    <link rel="stylesheet" type="text/css" href="external/toastify/toastify.css"/>
>    <link rel="stylesheet" type="text/css" href="external/contextual/contextual.css"/>
299,302c299,302
<     <script src="/protocol.js" defer></script>
<     <script src="/external/toastify/toastify.js" defer></script>
<     <script src="/external/contextual/contextual.js" defer></script>
<     <script src="/galene.js" defer></script>
---
>    <script src="protocol.js" defer></script>
>    <script src="external/toastify/toastify.js" defer></script>
>    <script src="external/contextual/contextual.js" defer></script>
>    <script src="galene.js" defer></script>
diff -r galene.old/index.html galene/index.html
7,9c7,9
<     <link rel="stylesheet" href="/common.css">
<     <link rel="stylesheet" href="/mainpage.css">
<     <link rel="stylesheet" type="text/css" href="/galene.css"/>
---
>    <link rel="stylesheet" href="common.css">
>    <link rel="stylesheet" href="mainpage.css">
>    <link rel="stylesheet" type="text/css" href="galene.css"/>
36c36
<     <script src="/mainpage.js" defer></script>
---
>    <script src="mainpage.js" defer></script>
diff -r galene.old/stats.html galene/stats.html
7c7
<     <link rel="stylesheet" href="/common.css">
---
>    <link rel="stylesheet" href="common.css">
15c15
<     <script src="/stats.js" defer></script>
---
>    <script src="stats.js" defer></script>