Frontend displays a blank page after setting up with Docker #1732

New Issue

leggettc18 · 2020-06-21T00:10:59Z

leggettc18 commented

2020-06-21 00:10:59 +00:00

I attempted to set up Vikunja based off of the Full Docker Example in your documentation, adapting it for my needs. Logs indicate the database migrations were applied successfully, and I can access the api docs at tasks.mydomain.tld/api/v1/docs. I can navigate to the frontend and based on the source inspector and network tabs in Firefox devtools it appears to receive the front page (I can see the blank div that should be containing the Vue stuff), but it doesn't seem to be communicating with the api properly, resulting in a blank page.

Docker Compose file

version: '3'

services:
    vikunja-db:
        image: mariadb:10
        container_name: vikunja-db
        hostname: vikunja-db
        environment:
            MYSQL_ROOT_PASSWORD: supersecret
            MYSQL_DATABASE: vikunja
        volumes:
            - ./vikunja-db-data:/var/lib/mysql
        restart: unless-stopped
    vikunja-api:
        image: vikunja/api
        container_name: vikunja-api
        hostname: vikunja-api
        environment:
            VIKUNJA_DATABASE_HOST: vikunja-db
            VIKUNJA_DATABASE_PASSWORD: supersecret
            VIKUNJA_DATABASE_TYPE: mysql
            VIKUNJA_DATABASE_USER: root
            VIKUNJA_DATABASE_DATABASE: vikunja
            VIKUNJA_SERVICE_FRONTENDURL: "https://tasks.mydomain.tld"
        env_file: .env
        volumes:
            - ./vikunja-data:/app/vikunja/files
        depends_on:
            - vikunja-db
        restart: unless-stopped
    vikunja-frontend:
        image: vikunja/frontend
        container_name: vikunja-frontend
        hostname: vikunja-frontend
        env_file: .env
        environment:
            VIKUNJA_API_URL: "https://tasks.mydomain.tld/api/v1"
        restart: unless-stopped
networks:
    default:
        external:
            name: $DOCKER_MY_NETWORK

Caddyfile

tasks.{$MY_DOMAIN} {
    handle / {
        reverse_proxy vikunja-frontend:80
    }
    handle /api/* {
        reverse_proxy vikunja-api:3456
    }
}

I attempted to set up Vikunja based off of the Full Docker Example in your documentation, adapting it for my needs. Logs indicate the database migrations were applied successfully, and I can access the api docs at `tasks.mydomain.tld/api/v1/docs`. I can navigate to the frontend and based on the source inspector and network tabs in Firefox devtools it appears to receive the front page (I can see the blank div that should be containing the Vue stuff), but it doesn't seem to be communicating with the api properly, resulting in a blank page. Docker Compose file ``` version: '3' services: vikunja-db: image: mariadb:10 container_name: vikunja-db hostname: vikunja-db environment: MYSQL_ROOT_PASSWORD: supersecret MYSQL_DATABASE: vikunja volumes: - ./vikunja-db-data:/var/lib/mysql restart: unless-stopped vikunja-api: image: vikunja/api container_name: vikunja-api hostname: vikunja-api environment: VIKUNJA_DATABASE_HOST: vikunja-db VIKUNJA_DATABASE_PASSWORD: supersecret VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: root VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_FRONTENDURL: "https://tasks.mydomain.tld" env_file: .env volumes: - ./vikunja-data:/app/vikunja/files depends_on: - vikunja-db restart: unless-stopped vikunja-frontend: image: vikunja/frontend container_name: vikunja-frontend hostname: vikunja-frontend env_file: .env environment: VIKUNJA_API_URL: "https://tasks.mydomain.tld/api/v1" restart: unless-stopped networks: default: external: name: $DOCKER_MY_NETWORK ``` Caddyfile ``` tasks.{$MY_DOMAIN} { handle / { reverse_proxy vikunja-frontend:80 } handle /api/* { reverse_proxy vikunja-api:3456 } } ```

konrad commented

2020-06-21 10:22:07 +00:00

There seems to be an issue with your reverse proxy configuration since it does not seem to be able to load the assets (look at the size):

curl indicates there's always an empty response from caddy:

$ curl -I https://tasks.mydomain.tld/css/chunk-vendors.a3fbd5f1.css
HTTP/2 200 
server: Caddy
date: Sun, 21 Jun 2020 10:12:00 GMT

Even for nonexisting paths:

$ curl -I https://tasks.mydomain.tld/40404040440404                
HTTP/2 200 
server: Caddy
date: Sun, 21 Jun 2020 10:13:52 GMT

API paths seem to work though:

$ curl -I https://tasks.mydomain.tld/api/v1/info
HTTP/2 405 
access-control-allow-origin: *
date: Sun, 21 Jun 2020 10:14:24 GMT
server: Caddy
vary: Origin

Your docker-compose file seems to be correct though, so I guess the caddy configuration is to blame here. Unfortunately I don't know much about caddy to be much helpful here.
Since we're getting the html from the index page of the frontend, caddy is able to reach the container at all (That would've been something I'd look for). But other than that, I'm afraid I can't help you with the caddy part.

There seems to be an issue with your reverse proxy configuration since it does not seem to be able to load the assets (look at the size): ![image](/attachments/6b95908f-5d1e-4360-9cd3-6f1766b65e15) `curl` indicates there's always an empty response from caddy: ``` $ curl -I https://tasks.mydomain.tld/css/chunk-vendors.a3fbd5f1.css HTTP/2 200 server: Caddy date: Sun, 21 Jun 2020 10:12:00 GMT ``` Even for nonexisting paths: ``` $ curl -I https://tasks.mydomain.tld/40404040440404 HTTP/2 200 server: Caddy date: Sun, 21 Jun 2020 10:13:52 GMT ``` API paths seem to work though: ``` $ curl -I https://tasks.mydomain.tld/api/v1/info HTTP/2 405 access-control-allow-origin: * date: Sun, 21 Jun 2020 10:14:24 GMT server: Caddy vary: Origin ``` Your docker-compose file seems to be correct though, so I guess the caddy configuration is to blame here. Unfortunately I don't know much about caddy to be much helpful here. Since we're getting the html from the index page of the frontend, caddy is able to reach the container at all (That would've been something I'd look for). But other than that, I'm afraid I can't help you with the caddy part.

leggettc18 commented

2020-06-21 17:17:23 +00:00

Ah OK, the whole "not loading assets" thing gave me a better hint of what could actually be happening. If I change the handle directives in Caddy to the following:

tasks.{$MY_DOMAIN} {
    handle /api/* {
        reverse_proxy vikunja-api:3456
    }
    handle /* {
        reverse_proxy vikunja-frontend:80
    }
}

Basically the /css wasn't getting handled by anything, just /, changing the match string to /* allowed that handle tag to match anything (other than /api/*, which gets grabbed by the first handle directive). When I change it to that I get to a login screen. However, when I try to register, I just get a blank red box, which looks like there should be an error but no text. The javascript console then just says "uncaught exception: undefined" I'll investigate more on my end in the meantime, but do you have any potential clues?

EDIT: Just thought to check the Network tab in dev tools, attempting to register gets me a 502, so I guess its definitely Caddy again... As a side note, is your documentation in a repo somewhere? If I ever get this figured out it might be useful to add a Caddy v2 section.

Ah OK, the whole "not loading assets" thing gave me a better hint of what could actually be happening. If I change the handle directives in Caddy to the following: ``` tasks.{$MY_DOMAIN} { handle /api/* { reverse_proxy vikunja-api:3456 } handle /* { reverse_proxy vikunja-frontend:80 } } ``` Basically the /css wasn't getting handled by anything, just /, changing the match string to /\* allowed that handle tag to match anything (other than /api/\*, which gets grabbed by the first handle directive). When I change it to that I get to a login screen. However, when I try to register, I just get a blank red box, which looks like there should be an error but no text. The javascript console then just says "uncaught exception: undefined" I'll investigate more on my end in the meantime, but do you have any potential clues? EDIT: Just thought to check the Network tab in dev tools, attempting to register gets me a 502, so I guess its definitely Caddy again... As a side note, is your documentation in a repo somewhere? If I ever get this figured out it might be useful to add a Caddy v2 section.

konrad commented

2020-06-21 18:06:43 +00:00

Huh if its caddy again...

The docs are in the api repo.

Huh if its caddy again... The docs are in [the api repo](https://kolaente.dev/vikunja/api/src/branch/master/docs).

konrad commented

2020-06-21 18:48:59 +00:00

Okay so it seems like there's a bug in the api regarding registration which causes the api to crash when attemting to register - hence the 502.

konrad commented

2020-06-21 19:34:46 +00:00

I've pushed a fix for that in 5283f006f5, please update and try again. It was a frontend bug after all.

I've pushed a fix for that in https://kolaente.dev/vikunja/frontend/commit/5283f006f591e915dcb0262d5af91b6e6152b1dc, please update and try again. It was a frontend bug after all.

leggettc18 commented

2020-06-21 20:05:22 +00:00

Deleted my earlier message, forgot to run docker-compose pull first...

It works! I'm going to see about a pull request for the docs to append a Caddy configuration to the Full Docker example, in case anyone sees this before then, my Caddy configuration ended up being even simpler, didn't actually need the handle directives at all.

tasks.{$MY_DOMAIN} {
    reverse_proxy /api/* vikunja-api:3456
    reverse_proxy vikunja-frontend:80
}

Deleted my earlier message, forgot to run `docker-compose pull` first... It works! I'm going to see about a pull request for the docs to append a Caddy configuration to the Full Docker example, in case anyone sees this before then, my Caddy configuration ended up being even simpler, didn't actually need the `handle` directives at all. ``` tasks.{$MY_DOMAIN} { reverse_proxy /api/* vikunja-api:3456 reverse_proxy vikunja-frontend:80 } ```

👍 1

konrad commented

2020-06-21 20:24:07 +00:00

A PR would be awesome!

Glad it works for you now.

A PR would be awesome! Glad it works for you now.

leggettc18 commented

2020-06-22 01:49:40 +00:00

I'll look into it as soon as I have time. Thanks for being the rubber ducky for my Caddy config and fixing the frontend bug we found! I'll go ahead and close this since its resolved.

leggettc18 closed this issue

2020-06-22 01:49:40 +00:00

konrad referenced this issue from a commit

2024-02-07 14:00:33 +00:00

fix: loading list views would sometimes not get loaded

Sign in to join this conversation.