After two days of trying around, I desperately need help :-)

Good day

I fail to install Vikunja on my Debian VPS, bare metal. But I continue despite many fruitless hours. I would be very grateful for help, I do not want to give up.
And there I just can’t manage to link the GUI and the API, it always ends in CORS errors.

My scenario:
The Api is published via caddy to this address:
ht-tps://API.Example.de
(this works, when I call ht-tps://API.Example.de//api/v1 in the browser it shows "message “Not Found”. By the way without double // it doesn’t work)

The Gui is also published via caddy to this address:
ht-tps://GUI.Example.de/
The interface loads but it can’t connect to the API, no matter which address I enter there (or in the index.html source)
ht-tps://API.Example.de//api/v1 is not working, but all other variants don’t work either.
It displays: AxiosError: Network Error
and in the browser console I see a CORS error. Now I have spent several hours putting many cryptic CORS commands into my caddy file, it just doesn’t work.

Sorry if I’m being a little slow there, but this is really the most difficult installation of a selfhosted application for me so far. :smiley:

By the way I tried it on Docker, there it was easier, but my Docker has different problems which is why I don’t want to use it.

The Cors-Section of my config:


cors:

  enable: true

  origins:
    - "*"

  maxage: 120

I also tried using “staticpath:” to serve the Gui within the Api.
But how can I reach the gui then? At ht-tps://API.Example.de it is not displayed then. And I don’t want to really serve it under port 80 of my VPS.

My caddy file:

(trusted_proxy_list) {
	trusted_proxies 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 fc00::/7 127.0.0.1/8 ::1/128
}

(cors) {
  @cors_preflight method OPTIONS
  @cors header Origin {args.0}

  handle @cors_preflight {
    header Access-Control-Allow-Origin *
    header Access-Control-Allow-Methods *
    header Access-Control-Allow-Headers *
    header Access-Control-Max-Age "3600"
    respond "" 204
  }

  handle @cors {
    header Access-Control-Allow-Origin *
    header Access-Control-Expose-Headers *
  }
}



# Authelia Portal.

ams-auth.Example.de {
	reverse_proxy http://127.0.0.1:9091 {
		import trusted_proxy_list
	}
}

# vikunja

GUI.Example.de {
	
	@options {
    method OPTIONS
}

respond @options 204
	


	forward_auth http://127.0.0.1:9091 {
		uri /api/verify?rd=ht-tps://ams-auth.Example.de/
		copy_headers Remote-User Remote-Groups Remote-Name Remote-Email


		import trusted_proxy_list
	}

import cors ht-tps://GUI.Example.de
root * /etc/vikunja/gui
file_server


}


API.Example.de {
       
@options {
    method OPTIONS
}

respond @options 204



	    forward_auth http://127.0.0.1:9091 {
                uri /api/verify?rd=ht-tps://ams-auth.Example.de/
                copy_headers Remote-User Remote-Groups Remote-Name Remote-Email

                import trusted_proxy_list
				
        }



	import cors ht-tps://API.Example.de
	reverse_proxy /api/* http://127.0.0.1:3456 {
		                import trusted_proxy_list
						

	}
	reverse_proxy /.well-known/* http://127.0.0.1:3456 {
		                import trusted_proxy_list

	}
	reverse_proxy /dav/* http://127.0.0.1:3456 {
		                import trusted_proxy_list

	}


}



(I had to write HTTPS as HT-TPS to be able to post here as a newcomer, sorry for the circumstances)

Hi!

There is simply no handler at the root api path, hence the 404. /api/v1/info should give you a “real” response.

This might be one part of the problem. I’d guess it is caused by your caddy setup.

As for cors, the api should respond with the appropriate headers for the api.example.de domain. Can you check with the dev tools in the browser or curl what it responds with?

I don’t really know anything about Caddy so no sure how much I can help you with that, but check out the caddy example for the docker config: Full docker example | Vikunja
You should be able to adopt that for a solution without docker. That config makes api and frontend available under one domain, avoiding all cors issues.

Thanks a lot for your effort!
I have somehow managed to solive it now.
It actually seems to have been more of a caddy issue.
It seems random, but I want to mention it in case it helps someone too: I caddyed the Public DNS of my VPS plus port 3456 instead of an internal IP (or localhost).
With all other applications it works via IP/localhost, why not here I don’t know. But I’m glad to have finally done it. Tough one. :slight_smile:

1 Like