Use two different hostnames to access same instance

Technical Help
, ,
#1

Hello,

We are trying to set up a single instance of baserow and to make it available on two different hostnames, a private and a public internet facing one:

We are using baserow docker-compose install (not the single image), here’s our .env file:

BASEROW_CADDY_ADDRESSES=https://baserow.intranet.lan
BASEROW_PUBLIC_URL=https://baserow.intranet.lan
DATABASE_PASSWORD=***
EMAIL_SMTP=nonempty
EMAIL_SMTP_HOST=smtp.intranet.lan
EMAIL_SMTP_PASSWORD:
EMAIL_SMTP_PORT=25
EMAIL_SMTP_USER:
EMAIL_SMTP_USE_TLS:
FROM_EMAIL=user@company.com
HOST_PUBLISH_IP=0.0.0.0
REDIS_PASSWORD=***
SECRET_KEY=***
WEB_FRONTEND_PORT=80

This works, baserow is accessible from baserow.intranet.lan (with a minor tweak to docker-compose.yml to load our baserow.intranet.lan certificate) But we now also want to access it from the internet.

So we added an apache reverse proxy from baserow.intranet.lan to baserow.companydotcom. This works but the HTML code still referenced baserow.intranet.lan, preventing javascript and forms submission to work correctly.

Is that doable ? The end game is to allow only forms to be filled and submitted through the internet facing domain name (by configuring our reverse proxy to reject URI not beginning with /form/, /media/, etc.).

I tried tweaking BASEROW_EXTRA_ALLOWED_HOSTS and BASEROW_CADDY_ADDRESSES by adding both domains in different combination but it doesn’t work and I get a Backend URL mis-configuration detected on the login page.

I thought BASEROW_EXTRA_ALLOWED_HOSTS would do it but it’s not clear if this forces django to render URLs with hostname found in headers and in this variable or if it’s something else entirely.

Can baserow be setup to be accessible from two different domain in that way ?

Edit: There’s also the issue that Caddy tries to obtain a certificate from LE even though our reverse proxy terminates the SSL connection and setting up variables with baserow.companydotcom is problematic.

Thanks :).

1 Like
#2

Many URLs are generated based on BASEROW_PUBLIC_URL (they are not relative) so I don’t think it is easily possible to do.

#3

Since you do want to expose Baserow to the internet, why don’t you just configure Baserow on a public domain/address and let internal people use it too?

#4

Thanks !

I grepped the source code and it’s not clear to me the extent to which I could tweak urls:

[...]
./backend/src/baserow/config/settings/base.py:440:BASEROW_PUBLIC_URL = os.getenv("BASEROW_PUBLIC_URL")
./backend/src/baserow/config/settings/base.py:441:if BASEROW_PUBLIC_URL:
./backend/src/baserow/config/settings/base.py:442:    PUBLIC_BACKEND_URL = BASEROW_PUBLIC_URL
./backend/src/baserow/config/settings/base.py:443:    PUBLIC_WEB_FRONTEND_URL = BASEROW_PUBLIC_URL
./backend/src/baserow/config/settings/base.py:444:    if BASEROW_PUBLIC_URL == "http://localhost":
./backend/src/baserow/config/settings/base.py:446:            "WARNING: Baserow is configured to use a BASEROW_PUBLIC_URL of "
./backend/src/baserow/config/settings/base.py:449:            "Please set BASEROW_PUBLIC_URL if you will be accessing Baserow "
./.env.example:19:BASEROW_PUBLIC_URL=http://localhost
./config/vscode/.vscode/launch.json:57:                "BASEROW_PUBLIC_URL": "http://localhost:3000",
./web-frontend/modules/core/middleware/urlCheck.js:32:    if (process.env.BASEROW_PUBLIC_URL) {
./web-frontend/modules/core/middleware/urlCheck.js:33:      urlEnvVarsToCheck.push('BASEROW_PUBLIC_URL')
./web-frontend/modules/core/components/auth/AuthLogin.vue:138:              ' BASEROW_PUBLIC_URL or PUBLIC_BACKEND_URL environment variables. ' +
./web-frontend/modules/core/module.js:38:  const BASEROW_PUBLIC_URL = process.env.BASEROW_PUBLIC_URL
./web-frontend/modules/core/module.js:39:  if (BASEROW_PUBLIC_URL) {
./web-frontend/modules/core/module.js:40:    process.env.PUBLIC_BACKEND_URL = BASEROW_PUBLIC_URL
./web-frontend/modules/core/module.js:41:    process.env.PUBLIC_WEB_FRONTEND_URL = BASEROW_PUBLIC_URL
[...]

Could setting up a PUBLIC_BACKEND_URL and a different PUBLIC_WEB_FRONTEND_URL allows the frond-end to be exposed on the internet and the backend only accessible from an Intranet ? I suppose pages rendered on the PUBLIC_WEB_FRONTEND_URL would still try (and fail) to call PUBLIC_BACKEND_URL when submitting data though ?

#5

We want to expose our tools on the Internet as less as possible. Maybe that’s going to be the only option if we go through with that.

Also, we haven’t looked yet into migrating our current installation to a different domain and what pitfall there are.

#6

The migration should not be a problem, using the same database and just running on a different address should be fine.

allows the frond-end to be exposed on the internet and the backend only accessible from an Intranet ?

This is not possible. You need both services to be exposed to the internet as the requests from the frontend are performed by a browser, hence the backend needs to be accessible. Note that our frontend is not a backend application, but a Single Page App (SPA).

There is no security benefit of having private and public address. Once you have a public address, the result is the same.

#7

Thanks !

Thanks, that’s what I feared.

#8

If you have multiple domains, you would probably also run into problems with the password forgot and invite emails that are being send. Baserow expects there to be one single web-frontend domain, where it can generate links to.