HTTP 500 Error on WebDAV Endpoint /projects/ #1608

New Issue

Twirl0084 · 2023-10-05T01:42:29Z

Twirl0084 commented

2023-10-05 01:42:29 +00:00

Description

Good day, I am using my browser (Chrome, Firefox, both in normal and private modes) to request the WebDAV endpoints to download the .ics files. This is a troubleshooting step I was doing because I thought the issue was with the integration in another solution I am working on. I am only looking at getting a basic list of projects without anything else.

I can download the file using the /dav/projects/1/ endpoint. The tasks display in the integration as well. The /dav/projects/ gives a HTTP 500 Error. I can reproduce the same behavior on try as well.

Using my mobile and accessing for the first time my instance, I logged on using the right credentials. I could read and edit my projects. Then I modified the URL in the address bar and I got prompt for my credentials again, but this time in a browser pop up dialog. Using the same credentials I got another HTTP 500 Error.

I tried to modify the header using curl as discussed in #753 but the brackets are added in the logs even when not sent as part of the header.

It seems that the authentication is not consistent from one WebDAV endpoint to another.

2023-10-04T20:58:00.631316417-04:00: WEB 	▶ 192.168.150.1  GET 200 /api/v1/notifications?page=1 2.708981ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36
2023-10-04T20:58:06.670621215-04:00: DEBUG	▶ caldav/ProjectHandler 0f4 [CALDAV] Request Body: 
2023-10-04T20:58:06.670708363-04:00: DEBUG	▶ caldav/ProjectHandler 0f5 [CALDAV] Request Headers: map[Accept:[text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7] Accept-Encoding:[gzip, deflate, br] Accept-Language:[en-US,en;q=0.9,fr;q=0.8] Authorization:[Basic SecretToken] Sec-Ch-Ua:["Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"] Sec-Ch-Ua-Mobile:[?0] Sec-Ch-Ua-Platform:["Windows"] Sec-Fetch-Dest:[document] Sec-Fetch-Mode:[navigate] Sec-Fetch-Site:[none] Sec-Fetch-User:[?1] Upgrade-Insecure-Requests:[1] User-Agent:[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36] X-Forwarded-For:[192.168.150.1] X-Forwarded-Host:[vikunja.redacted.ca] X-Forwarded-Port:[443] X-Forwarded-Proto:[https] X-Forwarded-Server:[456032bf8977] X-Real-Ip:[192.168.150.1]]
2023-10-04T20:58:06.670914542-04:00: WEB 	▶ 192.168.150.1  GET 500 /dav/projects/ 538.210152ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36

vikunja-frontend:0.21.0
vikunja-api:0.21.0

Cheers!

Vikunja Frontend Version

0.21.0

Vikunja API Version

0.21.0

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

Yes

Screenshots

No response

### Description Good day, I am using my browser (Chrome, Firefox, both in normal and private modes) to request the WebDAV endpoints to download the .ics files. This is a troubleshooting step I was doing because I thought the issue was with the integration in another solution I am working on. I am only looking at getting a basic list of projects without anything else. I can download the file using the `/dav/projects/1/` endpoint. The tasks display in the integration as well. The `/dav/projects/` gives a HTTP 500 Error. I can reproduce the same behavior on [try](https://try.vikunja.io/dav/projects/) as well. Using my mobile and accessing for the first time my instance, I logged on using the right credentials. I could read and edit my projects. Then I modified the URL in the address bar and I got prompt for my credentials again, but this time in a browser pop up dialog. Using the same credentials I got another HTTP 500 Error. I tried to modify the header using curl as discussed in [#753](https://kolaente.dev/vikunja/api/issues/753#issuecomment-45923) but the brackets are added in the logs even when not sent as part of the header. It seems that the authentication is not consistent from one WebDAV endpoint to another. ``` 2023-10-04T20:58:00.631316417-04:00: WEB ▶ 192.168.150.1 GET 200 /api/v1/notifications?page=1 2.708981ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 2023-10-04T20:58:06.670621215-04:00: DEBUG ▶ caldav/ProjectHandler 0f4 [CALDAV] Request Body: 2023-10-04T20:58:06.670708363-04:00: DEBUG ▶ caldav/ProjectHandler 0f5 [CALDAV] Request Headers: map[Accept:[text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7] Accept-Encoding:[gzip, deflate, br] Accept-Language:[en-US,en;q=0.9,fr;q=0.8] Authorization:[Basic SecretToken] Sec-Ch-Ua:["Chromium";v="116", "Not)A;Brand";v="24", "Google Chrome";v="116"] Sec-Ch-Ua-Mobile:[?0] Sec-Ch-Ua-Platform:["Windows"] Sec-Fetch-Dest:[document] Sec-Fetch-Mode:[navigate] Sec-Fetch-Site:[none] Sec-Fetch-User:[?1] Upgrade-Insecure-Requests:[1] User-Agent:[Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36] X-Forwarded-For:[192.168.150.1] X-Forwarded-Host:[vikunja.redacted.ca] X-Forwarded-Port:[443] X-Forwarded-Proto:[https] X-Forwarded-Server:[456032bf8977] X-Real-Ip:[192.168.150.1]] 2023-10-04T20:58:06.670914542-04:00: WEB ▶ 192.168.150.1 GET 500 /dav/projects/ 538.210152ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 ``` vikunja-frontend:0.21.0 vikunja-api:0.21.0 Cheers! ### Vikunja Frontend Version 0.21.0 ### Vikunja API Version 0.21.0 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? Yes ### Screenshots _No response_

Twirl0084 added the

kind/bug

label 2023-10-05 01:42:29 +00:00

konrad commented

2023-10-11 16:51:34 +00:00

What should it do on /projects/? It fails because there's no project ID in the url so this is kind of expected.

What should it do on `/projects/`? It fails because there's no project ID in the url so this is kind of expected.

Twirl0084 commented

2023-10-11 20:09:37 +00:00

Thank you for the reply. It is my understanding as per the docs that /projects/ is a valid WebDAV endpoint where the list of projects is returned, similarly to /projects/[ID] returns the tasks of a given project ID.

Thank you for the reply. It is my understanding as per the [docs](https://vikunja.io/docs/caldav/#urls) that `/projects/` is a valid WebDAV endpoint where the list of projects is returned, similarly to `/projects/[ID]` returns the tasks of a given project ID.

konrad commented

2023-10-11 21:12:03 +00:00

The docs may be wrong or GET is not the correct http method to access it. IIRC the correct approach to get a list with all is using the /dav/principals/<username> endpoint.

The docs may be wrong or GET is not the correct http method to access it. IIRC the correct approach to get a list with all is using the `/dav/principals/<username>` endpoint.

Twirl0084 commented

2023-10-12 11:46:50 +00:00

I might be doing something wrong here, but the ics file from /dav/principals/<username> downloads, but it is empty. I tried it on try.vikunja.io/dav/principals/demo and it is empty as well.

I might be doing something wrong here, but the ics file from `/dav/principals/<username>` downloads, but it is empty. I tried it on [try.vikunja.io/dav/principals/demo](https://try.vikunja.io/dav/principals/demo) and it is empty as well.

konrad commented

2024-01-28 16:03:29 +00:00

I might be doing something wrong here, but the ics file from /dav/principals/<username> downloads, but it is empty. I tried it on try.vikunja.io/dav/principals/demo and it is empty as well.

That's kind of by design. To get a list of all projects, you need to do a PROPFIND request specifying what you want to get back, not just a GET request (which is what you're doing in the browser.

You can try it with curl:

curl -X PROPFIND -u demo:demo -H "Content-Type: application/xml" -H "Depth: 0" -d '<?xml version="1.0" encoding="utf-8" ?><D:propfind xmlns:D="DAV:"><D:prop><D:displayname/></D:prop></D:propfind>' https://try.vikunja.io/dav/projects

and it will give you a list with all projects back:

<?xml version="1.0" encoding="UTF-8"?>
<D:multistatus
	xmlns:D="DAV:"
	xmlns:C="urn:ietf:params:xml:ns:caldav"
	xmlns:CS="http://calendarserver.org/ns/">
	<D:response>
		<D:href>/dav/projects/2</D:href>
		<D:propstat>
			<D:prop>
				<D:displayname>Personal</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
	<D:response>
		<D:href>/dav/projects/6</D:href>
		<D:propstat>
			<D:prop>
				<D:displayname>test-b</D:displayname>
			</D:prop>
			<D:status>HTTP/1.1 200 OK</D:status>
		</D:propstat>
	</D:response>
</D:multistatus>

> I might be doing something wrong here, but the ics file from `/dav/principals/<username>` downloads, but it is empty. I tried it on [try.vikunja.io/dav/principals/demo](https://try.vikunja.io/dav/principals/demo) and it is empty as well. That's kind of by design. To get a list of all projects, you need to do a `PROPFIND` request specifying what you want to get back, not just a `GET` request (which is what you're doing in the browser. You can try it with curl: ``` curl -X PROPFIND -u demo:demo -H "Content-Type: application/xml" -H "Depth: 0" -d '<?xml version="1.0" encoding="utf-8" ?><D:propfind xmlns:D="DAV:"><D:prop><D:displayname/></D:prop></D:propfind>' https://try.vikunja.io/dav/projects ``` and it will give you a list with all projects back: ``` <?xml version="1.0" encoding="UTF-8"?> <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:CS="http://calendarserver.org/ns/"> <D:response> <D:href>/dav/projects/2</D:href> <D:propstat> <D:prop> <D:displayname>Personal</D:displayname> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> <D:response> <D:href>/dav/projects/6</D:href> <D:propstat> <D:prop> <D:displayname>test-b</D:displayname> </D:prop> <D:status>HTTP/1.1 200 OK</D:status> </D:propstat> </D:response> </D:multistatus> ```

konrad referenced this issue from a commit

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

chore(deps): update dependency vue-tsc to v0.32.0 (#1608)

Sign in to join this conversation.