Add ability to set a base URL for client

[voidel]

Currently the application only supports being run on the bare domain, i.e. https://website.com.

If you proxy the application into a subdir, for example https://website.com/ticketing, the application does not work, the resources will point to the bare domain.

This can be solved by creating an environment arg for the BASE_URL like many applications do, which will pre-append the subdir onto any other URL.

[potts99]

Nice idea, will implement it shortly

[potts99]

Currently the easiest and best solution is to put behind a proxy on a subdomain, much more practical in the long run and can be used with other features such as a Load Balancer, this might happen in the future but fo now will probably not be implemented

[voidel]

Thanks for replying. That's what I ended up doing. I didn't realise setting up proxies to subdomains was so trivial, that is what I'll be doing from now on.

[potts99]

I'll write a guide for the docs on how to set up an nginx proxy for future people. Thank you for trying us out. Currently we are in early alpha but we are working on constant improvements 👍

[tzw9373]

I'll write a guide for the docs on how to set up an nginx proxy for future people. Thank you for trying us out. Currently we are in early alpha but we are working on constant improvements 👍

Any word on the status of these docs? I run the Linuxserver SWAG container for a reverse proxy and am pretty familiar with the inner workings, but I can't get my standard subdomain setup working with this container. What should I be putting for the base url for that type of setup?

[potts99]

@tzw9373 Hi, currently not tried putting it behind a reverse proxy on this new update, got a fair bit on the old todo list ha.
Are you running the new version?

[tzw9373]

I am, just pulled the image and setup the container today!

[potts99]

oh neat!! well thank you firstly, second point is, i would say set the base url to the url you want to access it from then set the port to whichever you are directing to 80/443?

BASE_URL: "http://peppermint.example.com"
PORT: "443"

now i haven't tested this, I do have a lot of topics i want to write docs for -> reverse proxies, k8's set up etc. SO YOURE TECHINCALLY MY QA DEPARTMENT RIGHT NOW!

good luck my man haha

[tzw9373]

From my relatively basic understanding, I can say that most services technically remain visible/accessible only at their normal port (in this case 5000) and NGINX then connects traffic on https://peppermint.example.com -> 443 -> local IP -> 5000. Where I seem to be stalling out is that after user credentials are entered, the service tries to redirect to base URL + port which ends up being https://peppermint.example.com:5000/XXXXXXX. This throws an "error connection refused". If there's a way to make that port optional, I would think that would correct it. Or maybe there's a better way to handle that from the beginning, my experience is limited.

[potts99]

ah, in this case the port needs to be changed to 443/80 I think thats where you're having the issue, it's just how the auth currently works

[tzw9373]

The problem that I'm running into is that changing that port changes the port that the service listens on, and 443 is already used by the reverse proxy. Here's the line from the container log: ready - started server on 0.0.0.0:443, url: http://localhost:443. If there has to be a port in the redirect after completed auth and it can't be different from the port the server runs on, I don't think a reverse proxy will work.

[potts99]

Ah,
so when you set

PORT: 433

it still redirects you to 5000?

Linode gave me some test credits, let me spin a server this afternoon and see what i can get done

[tzw9373]

No, it would redirect to 443 if I was exposing that port in the port section instead of 5000:5000. But I can't/don't want to for the previously mentioned reasons. From my experience, services that work with reverse proxies don't have ports in any URL redirects. They're seen externally as https://service.example.com (if there was a port it would be 443) and internally as http://127.0.0.1:5000, with the reverse proxy translating between the two. Here's a writeup with tons of good info: https://www.linuxserver.io/blog/2017-11-28-how-to-setup-a-reverse-proxy-with-letsencrypt-ssl-for-all-your-docker-apps#whatisareverseproxy

[potts99]

@tzw9373 I think i have a fix for your issue, if you could try the below

version: "3.1"

services:
  postgres:
    container_name: postgres
    image: postgres:latest
    restart: always
    volumes:
      - ./peppermint/db:/data/db
    environment: 
      POSTGRES_USER: peppermint
      POSTGRES_PASSWORD: 1234
      POSTGRES_DB: peppermint

  client:
    container_name: peppermint
    image: pepperlabs/peppermint:test
    ports:
      - 3001:3001
    restart: on-failure
    depends_on:
      - postgres
    expose:
      - 3001
    environment:
      PORT: 3001
      DB_USERNAME: "peppermint"
      DB_PASSWORD: "1234"
      DB_HOST: "postgres"
      BASE_URL: "http://localhost:3001"

currently setting up a devbox to test this myself, but i would assume, you would just setting your base url to peppermint.example.com and nginx should take care of the rest?