405 Creating user and nginx blocking post request

Support
1

I’m using nginx and a manual installation of vikunja.
Calling http://mydomain/api/v1/info works, the api is exposed.
My nginx configuration looks fine comparing with the examples

server {
        server_name mydomain;
        listen 80;

        server_tokens off;
        include conf.d/htDenial.conf;
        client_max_body_size 10m;

        location / {
                root   /usr/local/share/webapps/vikunja-web/dist;
                try_files $uri $uri/ /;
                index  index.html index.htm;
                access_log /var/log/nginx/vikunya.static.access.log;

        }

        location ~* ^/(api|dav|\.well-known)/ {
                proxy_pass http://unix:/run/vikunja/vikunja.sock;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                access_log /var/log/nginx/vikunya.api.access.log;

        }
        access_log /var/log/nginx/vikunya.access.log;
        error_log /var/log/nginx/vikunya.error.log;
}

The web is up and working, so I try to create my first user, only for the CreateAccount button to respond with

Request failed with status code 405

Taking a look at the logs, I found that the POST request it makes, goes to the api location of nginx. Nginx can’t serve static content on POST request as I see in this post (nginx - 405 (Not Allowed) on POST request - Server Fault), sooo…

Should that happen? should that post request go to the other location? is the post request incorrect? the nginx configuration one?

2

Does the request show up in the Vikunja API logs?

3

Not at all, nothing in database, standard, http or event logs from vikunja, only that one from nginx, so looks like nginx is effectively blocking it.

4

Yeah that looks like nginx is the issue here. Can you check if the socket connection works? (I think curl has an option to connect to an http socket) Does it work if you use a port instead?

5

Sorry for the late response, my life got in the way.

So with curl I get the following response

curl --unix-socket /var/run/vikunja/vikunja.sock https://mydomain/register
curl: (35) OpenSSL/3.0.8: error:0A00010B:SSL routines::wrong version number

curl --unix-socket /var/run/vikunja/vikunja.sock http://mydomain/register
{"message":"Not Found"}

I removed the https part of the server, and changed the socket to use a port number, same behaviour/response.

I then added a new block location, specifically for the /register part of the domain, with the same content as the api location, and now it responds with a 404 error and the same {“message”:“Not Found”} given by curl.

location /register {
                proxy_pass http://localhost:3456;
                proxy_set_header Host $host;
                access_log /var/log/nginx/vikunjaregister;

                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;

        }

By the way, this request appears in vikunja logs (also all curl requests).

2023-05-02T15:39:43.194259861+02:00: WEB 	▶ 192.168.1.1  POST 404 /register 39.293µs - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

I’m trying to give with curl a full request, all details inclulded, but I’m getting the same message.

curl -X POST http://localhost:3456/register  -d '[username: "aName", email: "an_email@gmail.com", password: "aPassword"]'
6

The api only responds to requests at /api/v1/*, /dav/* and /.well-known. In your case the request should go to /api/v1/register, not /register.

7

Ok, I got the issue then, basically the vikunja url I set was something like
http://mydomain.es

And instead, it worked with
http://mydomain.es/api/v1

I thought the /api/v1 wasn’t necessary as I saw no complains without it (that the website found the vikunja installation in that url anyway)
Maybe an improvement would be hardening that url check to avoid this silly mistake. Or is there a configuration in config.yml in order to automatically add the /api/v1 if I just enter mydomain.es?

Gonna try again with sockets and https.

8

The url check in the frontend does that, but if your reverse proxy configuration is wrong the frontend can’t access the api.

9

I mean, having the nginx correctly as per the initial message, introducing https://mydomain.es in frontend, it returns good
the same as https://mydomain.es/api/v1
and wrong if it’s something like… https://mydomain.es/api
Not sure how it’s doing the check.

In any case, it is working with sockets and https as well, so everything good for me ^^

1 Like