* [Galene] Behind reverse proxy, not at the root @ 2024-01-17 23:40 Francis Bolduc 2024-01-18 11:08 ` [Galene] " Juliusz Chroboczek 2024-02-24 11:49 ` Juliusz Chroboczek 0 siblings, 2 replies; 19+ messages in thread From: Francis Bolduc @ 2024-01-17 23:40 UTC (permalink / raw) To: galene 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-01-17 23:40 [Galene] Behind reverse proxy, not at the root Francis Bolduc @ 2024-01-18 11:08 ` Juliusz Chroboczek 2024-01-18 14:56 ` Francis Bolduc 2024-02-24 11:49 ` Juliusz Chroboczek 1 sibling, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-01-18 11:08 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-01-18 11:08 ` [Galene] " Juliusz Chroboczek @ 2024-01-18 14:56 ` Francis Bolduc 0 siblings, 0 replies; 19+ messages in thread From: Francis Bolduc @ 2024-01-18 14:56 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-01-17 23:40 [Galene] Behind reverse proxy, not at the root Francis Bolduc 2024-01-18 11:08 ` [Galene] " Juliusz Chroboczek @ 2024-02-24 11:49 ` Juliusz Chroboczek 2024-02-24 14:34 ` Francis Bolduc 1 sibling, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-24 11:49 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 11:49 ` Juliusz Chroboczek @ 2024-02-24 14:34 ` Francis Bolduc 2024-02-24 18:27 ` Francis Bolduc 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-24 14:34 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 14:34 ` Francis Bolduc @ 2024-02-24 18:27 ` Francis Bolduc 2024-02-24 18:44 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-24 18:27 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 18:27 ` Francis Bolduc @ 2024-02-24 18:44 ` Juliusz Chroboczek 2024-02-24 18:56 ` Francis Bolduc 0 siblings, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-24 18:44 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 18:44 ` Juliusz Chroboczek @ 2024-02-24 18:56 ` Francis Bolduc 2024-02-24 20:12 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-24 18:56 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 18:56 ` Francis Bolduc @ 2024-02-24 20:12 ` Juliusz Chroboczek 2024-02-24 21:28 ` Francis Bolduc 0 siblings, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-24 20:12 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 20:12 ` Juliusz Chroboczek @ 2024-02-24 21:28 ` Francis Bolduc 2024-02-24 22:16 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-24 21:28 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 21:28 ` Francis Bolduc @ 2024-02-24 22:16 ` Juliusz Chroboczek 2024-02-24 22:19 ` Francis Bolduc 0 siblings, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-24 22:16 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 22:16 ` Juliusz Chroboczek @ 2024-02-24 22:19 ` Francis Bolduc 2024-02-24 22:49 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-24 22:19 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 22:19 ` Francis Bolduc @ 2024-02-24 22:49 ` Juliusz Chroboczek 2024-02-25 0:51 ` Francis Bolduc 0 siblings, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-24 22:49 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-24 22:49 ` Juliusz Chroboczek @ 2024-02-25 0:51 ` Francis Bolduc 2024-02-25 11:10 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Francis Bolduc @ 2024-02-25 0:51 UTC (permalink / raw) To: Juliusz Chroboczek; +Cc: galene 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-25 0:51 ` Francis Bolduc @ 2024-02-25 11:10 ` Juliusz Chroboczek 2024-03-03 15:20 ` Juliusz Chroboczek 0 siblings, 1 reply; 19+ messages in thread From: Juliusz Chroboczek @ 2024-02-25 11:10 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-02-25 11:10 ` Juliusz Chroboczek @ 2024-03-03 15:20 ` Juliusz Chroboczek 2024-03-03 15:30 ` Dianne Skoll [not found] ` <170947981403.1000.17286547855683116289@gauss.local> 0 siblings, 2 replies; 19+ messages in thread From: Juliusz Chroboczek @ 2024-03-03 15:20 UTC (permalink / raw) To: Francis Bolduc; +Cc: galene >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root 2024-03-03 15:20 ` Juliusz Chroboczek @ 2024-03-03 15:30 ` Dianne Skoll [not found] ` <170947981403.1000.17286547855683116289@gauss.local> 1 sibling, 0 replies; 19+ messages in thread From: Dianne Skoll @ 2024-03-03 15:30 UTC (permalink / raw) To: galene 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <170947981403.1000.17286547855683116289@gauss.local>]
* [Galene] Re: Behind reverse proxy, not at the root [not found] ` <170947981403.1000.17286547855683116289@gauss.local> @ 2024-03-03 15:52 ` Juliusz Chroboczek 2024-03-03 16:04 ` Dirk-Willem van Gulik 1 sibling, 0 replies; 19+ messages in thread From: Juliusz Chroboczek @ 2024-03-03 15:52 UTC (permalink / raw) To: Dianne Skoll; +Cc: galene >> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Galene] Re: Behind reverse proxy, not at the root [not found] ` <170947981403.1000.17286547855683116289@gauss.local> 2024-03-03 15:52 ` Juliusz Chroboczek @ 2024-03-03 16:04 ` Dirk-Willem van Gulik 1 sibling, 0 replies; 19+ messages in thread From: Dirk-Willem van Gulik @ 2024-03-03 16:04 UTC (permalink / raw) To: Dianne Skoll 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> ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2024-03-03 16:07 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-17 23:40 [Galene] Behind reverse proxy, not at the root Francis Bolduc 2024-01-18 11:08 ` [Galene] " Juliusz Chroboczek 2024-01-18 14:56 ` Francis Bolduc 2024-02-24 11:49 ` Juliusz Chroboczek 2024-02-24 14:34 ` Francis Bolduc 2024-02-24 18:27 ` Francis Bolduc 2024-02-24 18:44 ` Juliusz Chroboczek 2024-02-24 18:56 ` Francis Bolduc 2024-02-24 20:12 ` Juliusz Chroboczek 2024-02-24 21:28 ` Francis Bolduc 2024-02-24 22:16 ` Juliusz Chroboczek 2024-02-24 22:19 ` Francis Bolduc 2024-02-24 22:49 ` Juliusz Chroboczek 2024-02-25 0:51 ` Francis Bolduc 2024-02-25 11:10 ` Juliusz Chroboczek 2024-03-03 15:20 ` Juliusz Chroboczek 2024-03-03 15:30 ` Dianne Skoll [not found] ` <170947981403.1000.17286547855683116289@gauss.local> 2024-03-03 15:52 ` Juliusz Chroboczek 2024-03-03 16:04 ` Dirk-Willem van Gulik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox