Caldav URL should have a domain prefix if the API URL starts with /API/v1 #1763

New Issue

Ghost · 2021-01-15T01:10:01Z

Ghost commented

2021-01-15 01:10:01 +00:00

Was trying to figure out why the caldav textbox under settings keeps showing: /dav/principals/{USERNAME}/. And not prepending my custom domain before that link.

Did some searching and came to the lines here:
https://kolaente.dev/vikunja/frontend/src/branch/master/src/views/user/Settings.vue#L420-L421
And saw that it was based on API_URL. Which when I check in browser is /api/v1.

So followed the instructions here: https://vikunja.io/docs/install-frontend/#api-url-configuration-in-docker. But noticed the problem was still occuring.

Looked into the run.sh script to see the replacement for the environment variable. And it looks like the logic is a bit out of sync. So I ran the container directly to see what the file looks like at /usr/share/nginx/html/index.html without running run.sh.

So did:

docker run --rm -it vikunja/frontend sh
cat /usr/share/nginx/html/index.html
And this is the block that seems relevant:

// This variable points the frontend to the api.
// It has to be the full url, including the last /api/v1 part and port.
// You can change this if your api is not reachable on the same port as the frontend.
        window.API_URL = '/api/v1'

But the it seems the sed in run.sh is expecting there to be http://localhost:3456/api/v1 in there.

So I manually entered my custom domain into that line and it filled the caldav link correctly.

Was trying to figure out why the caldav textbox under settings keeps showing: `/dav/principals/{USERNAME}/`. And not prepending my custom domain before that link. Did some searching and came to the lines here: https://kolaente.dev/vikunja/frontend/src/branch/master/src/views/user/Settings.vue#L420-L421 And saw that it was based on API_URL. Which when I check in browser is `/api/v1`. So followed the instructions here: https://vikunja.io/docs/install-frontend/#api-url-configuration-in-docker. But noticed the problem was still occuring. Looked into the `run.sh` script to see the replacement for the environment variable. And it looks like the logic is a bit out of sync. So I ran the container directly to see what the file looks like at `/usr/share/nginx/html/index.html` without running `run.sh`. So did: - `docker run --rm -it vikunja/frontend sh` - `cat /usr/share/nginx/html/index.html` And this is the block that seems relevant: ``` // This variable points the frontend to the api. // It has to be the full url, including the last /api/v1 part and port. // You can change this if your api is not reachable on the same port as the frontend. window.API_URL = '/api/v1' ``` But the it seems the `sed` in `run.sh` is expecting there to be `http://localhost:3456/api/v1` in there. So I manually entered my custom domain into that line and it filled the caldav link correctly.

Ghost changed title from ~~API_URL ignored by run.sh~~ to VIKUNJA_API_URL ignored by run.sh

2021-01-15 01:10:22 +00:00

konrad commented

2021-01-15 06:53:44 +00:00

So I manually entered my custom domain into that line and it filled the caldav link correctly.

That'll fix it temporaily, but the modifications will be gone once you restart the container.

The localhost... part isn't present in the file anymore because sed already replaced it. I think the real problem is the caldav URL needs to the domain of the current URL if the API URL starts with /api/....

> So I manually entered my custom domain into that line and it filled the caldav link correctly. That'll fix it temporaily, but the modifications will be gone once you restart the container. The `localhost...` part isn't present in the file anymore because sed already replaced it. I think the real problem is the caldav URL needs to the domain of the current URL if the API URL starts with `/api/...`.

konrad added the

kind/bug

label 2021-01-15 06:53:50 +00:00

konrad changed title from ~~VIKUNJA_API_URL ignored by run.sh~~ to Caldav URL should have a domain prefix if the API URL starts with /API/v1

2021-01-15 06:54:42 +00:00

Ghost commented

2021-01-15 13:15:04 +00:00

That could also be a solution.

But just for debugging, the localhost is not already gone. By running that docker command, sh replaces the CMD set by the Dockerfile. So the run.sh is not ran in that instance.

From https://docs.docker.com/engine/reference/builder/#cmd:

If the user specifies arguments to docker run then they will override the default specified in CMD.

That could also be a solution. But just for debugging, the `localhost` is not already gone. By running that docker command, `sh` replaces the `CMD` set by the `Dockerfile`. So the `run.sh` is not ran in that instance. From https://docs.docker.com/engine/reference/builder/#cmd: > If the user specifies arguments to docker run then they will override the default specified in CMD.

konrad commented

2021-01-15 19:46:56 +00:00

Looks like I misread that docker run for docker exec - my bad.

The docs about CMD you cited explain why the url is not replaced correctly when you debug it with docker run.

Replacing the url seems to work though:

$ docker run -p 8888:80 -d vikunja/frontend 
$ curl http://localhost:8888
... content ommitted ...
<script>//
	// This variable points the frontend to the api.
	// It has to be the full url, including the last /api/v1 part and port.
	// You can change this if your api is not reachable on the same port as the frontend.
	window.API_URL = '/api/v1'
    //</script>
... content ommitted ...

Looks like I misread that `docker run` for `docker exec` - my bad. The docs about `CMD` you cited explain why the url is not replaced correctly when you debug it with `docker run`. Replacing the url seems to work though: ``` $ docker run -p 8888:80 -d vikunja/frontend $ curl http://localhost:8888 ... content ommitted ... <script>// // This variable points the frontend to the api. // It has to be the full url, including the last /api/v1 part and port. // You can change this if your api is not reachable on the same port as the frontend. window.API_URL = '/api/v1' //</script> ... content ommitted ... ```

konrad commented

2021-01-15 19:57:48 +00:00

I've fixed the missing url prefix in db90a8cde4 - feel free to reopen if the problem isn't solved.

I've fixed the missing url prefix in https://kolaente.dev/vikunja/frontend/commit/db90a8cde4cd67857718c557834ac87c106b211e - feel free to reopen if the problem isn't solved.

konrad closed this issue

2021-01-15 19:57:48 +00:00

Ghost commented

2021-01-15 20:54:31 +00:00

Cool. I will retest with new version. Thanks!

xeruf commented

2022-07-07 19:37:23 +00:00

So this should be fixed if I understand the issue correctly?
Because it doesn't seem so :/

So this should be fixed if I understand the issue correctly? Because it doesn't seem so :/ ![image](/attachments/9e7b0a72-8b5c-45ca-96fe-f4c12b9396b1)

image.png

21 KiB

konrad commented

2022-07-07 20:36:14 +00:00

What version are you using? This seems to work fine on try:

What version are you using? This seems to work fine on [try](https://try.vikunja.io): ![image](/attachments/bb2f88be-fc4d-4279-a9dc-05f662d914a8)

image.png

12 KiB

xeruf commented

2022-07-08 08:04:26 +00:00

latest - 0.18.2 - as always
I think I need to open a feature request to gitea to add project-specific information to ones profile, so people don't have to state their version in every issue.

latest - 0.18.2 - as always I think I need to open a feature request to gitea to add project-specific information to ones profile, so people don't have to state their version in every issue.

konrad commented

2022-07-08 12:39:08 +00:00

Did you configure an api url?

I think I need to open a feature request to gitea to add project-specific information to ones profile, so people don't have to state their version in every issue.

There are issue templates which could be used for that.

Did you configure an api url? > I think I need to open a feature request to gitea to add project-specific information to ones profile, so people don't have to state their version in every issue. There are [issue templates](https://docs.gitea.io/en-us/issue-pull-request-templates/) which could be used for that.

xeruf commented

2022-07-08 14:49:18 +00:00

Not explicitly, no - but it works with the default, so why doesn't it display the default there either?

With issue templates I still have to reiterate my info on every issue, see https://github.com/go-gitea/gitea/issues/20291

Not explicitly, no - but it works with the default, so why doesn't it display the default there either? With issue templates I still have to reiterate my info on every issue, see https://github.com/go-gitea/gitea/issues/20291

👍 1

konrad commented

2022-07-08 14:51:32 +00:00

It should work with the default, yes. Can you check if it works with the unstable build?

xeruf referenced this issue from vikunja/frontend

2022-07-09 01:38:59 +00:00

URL Prefix missing in links if not explicitly configured #1929

konrad referenced this issue from a commit

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

chore(deps): update dependency vitest to v0.8.4 (#1763)

Sign in to join this conversation.