Flarum server with different response behaviour, accessed locally or remotely

jonos

The issue:

I apologize if posting to the wrong place...

I am trying out a Flarum forum server.

The forum server is on the inside of a router, and my problem is that accessing the forum from
the local environment or from the outside internet works differently. From the inside everything
functions correctly, but from the external internet the forum GUI page never appears on the browser client,
only some few text-only lines containing the forum tags shows up.

My server is located inside a "safe" environment, protected by several routers.
This is how it looks:

In the Flarum configuration config.php I have
'url' => 'http://192.168.1.112'

Flarum uses port 80.
From the local network (say 192.168.1.113) I can access the Forum server,
by 'http://192.168.1.112', all is fine.

However, from internet, I need to access differently. I cannot use port 80 as this is used internally for other purposes.

So I access by
'http://a.b.c.d:81'.

Therefore, in the outer router I NAT from port 80 to 81 and in the security router I allow port 81 to port 81.
This works fine in general and packets does flow as intended.

Replacing Flarum with a general http server, both internal and internet access works flawlessly.
However, with Flarum this is different. So what I see is a Flarum related issue.

Inspecting the HTTP packets received on the forum server from a local machine, I find:
GET / HTTP/1.1
Host: 192.168.1.112

but from an external client I find:
GET / HTTP/1.1
Host: a.b.c.d:81

So I guess my question is this:
What is the purpose behind Flarum caring about whether the GET request actually matches the 'url'
item in the config.php or not. Why this match requirement??? (given that this is the reason I observe what I
do, of course.)
Can this matching requirement be disabled somehow, or is this a bad idea??
I am just trying to wrap my head around this...

Thanks to anyone who can explain...

jonos

Just to continue my own rant from above...

Assuming that my problem was the one I described above, I realized that if I just created a
DNS record with a a suitable name pointing to the physical server, everything should work both
locally and externally from the global internet.

So to test this I created a DNS record using (in my case) duckdns.org such that myservername.duckdns.org points to
my local server's global address (a.b.c.d in the previous description).

In this case I replaced the 'url' entry in config.php with
'url' => 'http://myservername.duckdns.org:81'

(I am obviously not using 'myservername' as such... :-))

Voila, that appears to to the trick as far as I can see!!

Anyway, I still do not understand why Flarum needs to inspect and react to the HTTP GET packet information,
so I am happy if anyone can explain why this is so...

clarkwinkelmann

Flarum only works when the URL in the address bar is the same as the one in config.php, because it always uses the URL from the config to load some assets and it causes cross-origin issues in browsers if the address used to load the forum is different.

If you need Flarum to work with multiple domain names/IPs, you can edit config.php with code so that the url config gets dynamically set based on the current server headers. There are some examples for this on this forum but I can't find them right now.

GreXXL

clarkwinkelmann I think this is what you're searching for: https://discuss.flarum.org/d/24952-how-can-i-add-multiple-domain-for-a-single-flarum-installation/4

jonos

Many thanks for responding to my question/rant.

I must say that I still really have a hard time understanding why the URL in the address bar must match the config.php url entry.
The sentence about "config to load some assets and it causes cross-origin issues in browsers" did not really tell me much.
For my life I cannot see that this requirement should be necessary (I realize you could prove me wrong, so please bear with me...)

If at all possible I would suggest this requirement be removed, and that the problem it currently solves should be handled in a different way. This requirement just causes complications for would-be users/managers.
Therefore: IMHO it should be kept on the TODO list for future improvements.

Further, I would like to understand better what specific issue(s) this requirement currently solves, it there any detailed
documentation available spelling it out??

I would also like to say that I am full of admiration about the work done here, so I am really not trying to to be unhelpful. Having solved my initial access problem through a DNS lookup, I can now move on to the next phase...

I just feel that removing this requirement (if possible) would lighten the burden on would-be users. And... being the guy I am, I really like to understand!!

So again, if at all possible, some more information, please... :-) :-) :-)

clarkwinkelmann

jonos one thing to understand is that the vast majority of forums don't need more than one origin (domain), so any change to this behavior will only affect a very small number of communities who might themselves have many different needs.

In a way, having the forum fail to load when using the wrong origin will even help operators realize when they incorrectly allowed accessing the forum from multiple origins, like the www/no-www subdomain, which causes duplicate URLs in search engines and would have a negative effect on SEO.

Other software do automatically load all assets (CSS, javascript, images) relative to the current visitor's origin, and Flarum could probably do the same, but it wouldn't solve everything. I believe storing the URL makes supporting subfolder installs easier, and also makes it easier to run Flarum behind a proxy without having to deal with the hostname being lost or replaced during translation.

But the most important reason for having the URL hard-coded are queues. As you scale a community, you will want to run tasks in asynchronous jobs, in particular for emails, and those need to be able to generate URLs. If your forum is accessible through multiple URLs, there will be some logic to write for the asynchronous jobs. If there is an internal and external domain, you will have to pick a default one for the emails, or store a preference for each user, or store which one to use alongside each task. If you have different domains/subdomains for aesthetics, you will likely want to attach the domains to specific tags, and also implement permanent redirects between domains for SEO canonical URLs.

All those use cases with multiple domains likely require custom code, hence why it doesn't make sense to support them out of the box in Flarum.

As for why browsers refuse to load ressources cross-domain, you should be able to find documentation on this online. Flarum is a single page app, and for the reasons above, it always tries to hit the JSON API at the specified URL. By default, browsers will block any attempt from a website to request data from another website, hence the errors and blank pages.

If you can use an identical domain name from inside and outside your organization and just route it differently inside the network, it solves all the issues in one go, SEO, queues, etc.