405 errors for register & login - binary install on VPS

(Thanks for providing a level of support even for us self-hosted users!)

I downloaded and setup the binary backend, NGINX config and manually installed the frontend. I’ve got a subdomain configured in Cloudflare, certbot gave me a certificate and the landing page loads successfully.

Trying to register or login gives a 405 error in the console and visiting “/api/v1/info” loads a blank page with the Vikunja logo. There are no logs in my Vikunja log destination and no relevant entries in the NGINX error log. I’m not sure where to start trying to debug this.

NGINX config:

server {
    server_name  sub.domain.com;

    location / {
        root   /var/www/vikunja;
        try_files $uri $uri/ /;
        index  index.html index.htm;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}
server {
    if ($host = sub.domain.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen       80;
    server_name  sub.domain.com;
    return 404; # managed by Certbot
}

Vikunja config (subset):

service:
  # This token is used to verify issued JWT tokens.
  # Default is a random token which will be generated at each startup of vikunja.
  # (This means all already issued tokens will be invalid once you restart vikunja)
  JWTSecret: "ubIzkNwHQWST1GuvdphHOIuPAlKu5Ytp"
  # The duration of the issed JWT tokens in seconds.
  # The default is 259200 seconds (3 Days).
  jwtttl: 259200
  # The duration of the "remember me" time in seconds. When the login request is made with
  # the long param set, the token returned will be valid for this period.
  # The default is 2592000 seconds (30 Days).
  jwtttllong: 2592000
  # The interface on which to run the webserver
  interface: ":3456"
  # Path to Unix socket. If set, it will be created and used instead of tcp
  unixsocket:
  # Permission bits for the Unix socket. Note that octal values must be prefixed by "0o", e.g. 0o660
  unixsocketmode:
  # The URL of the frontend, used to send password reset emails.
  frontendurl: "sub.domain.com"
  # The base path on the file system where the binary and assets are.
  # Vikunja will also look in this path for a config file, so you could provide only this variable to point to a folder
  # with a config file which will then be used.
  rootpath: /var/www/vikunja/
  # Path on the file system to serve static files from. Set to the path of the frontend files to host frontend alongside the api.
  staticpath: ""
  # The max number of items which can be returned per page
  maxitemsperpage: 50
  # Enable the caldav endpoint, see the docs for more details
  enablecaldav: true
  # Set the motd message, available from the /info endpoint
  motd: ""
  # Enable sharing of lists via a link
  enablelinksharing: true
  # Whether to let new users registering themselves or not
  enableregistration: true
  # Whether to enable task attachments or not
  enabletaskattachments: true
  # The time zone all timestamps are in. Please note that time zones have to use [the official tz database names](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). UTC or GMT offsets won't work.
  timezone: America/New_York
  # Whether task comments should be enabled or not
  enabletaskcomments: true
  # Whether totp is enabled. In most cases you want to leave that enabled.
  enabletotp: true
  # If not empty, enables logging of crashes and unhandled errors in sentry.
  sentrydsn: ''
  # If not empty, this will enable `/test/{table}` endpoints which allow to put any content in the database.
  # Used to reset the db before frontend tests. Because this is quite a dangerous feature allowing for lots of harm,
  # each request made to this endpoint neefs to provide an `Authorization: <token>` header with the token from below. <br/>
  # **You should never use this unless you know exactly what you're doing**
  testingtoken: ''
  # If enabled, vikunja will send an email to everyone who is either assigned to a task or created it when a task reminder
  # is due.
  enableemailreminders: true
  # If true, will allow users to request the complete deletion of their account. When using external authentication methods
  # it may be required to coordinate with them in order to delete the account. This setting will not affect the cli commands
  # for user deletion.
  enableuserdeletion: true
  # The maximum size clients will be able to request for user avatars.
  # If clients request a size bigger than this, it will be changed on the fly.
  maxavatarsize: 1024

Looks like you didn’t expose the api. The api needs to be accessible from the browser you’re using to view the frontend.

Check out the nginx reverse proxy example in the docs: Reverse Proxy | Vikunja

Well! I see that certbot rolled right over the reverse proxy section of the config. Sorry - I should have caught that myself!

I’ve added the relevant section (also using localhost instead of the IP address):

    location ~* ^/(api|dav|\.well-known)/ {
        proxy_pass http://127.0.0.1:3456;
        client_max_body_size 20M;
    }

That did make a little progress and I had a cavalcade of CORS errors. I disabled CORS and now I’m left with a 502 errors in the browser and NGINX logs have this with POST, GET and OPTIONS calls to the api:

*6 connect() failed (111: Connection refused) while connecting to upstream

Does that give you any useful information? (If so you’re ahead of me!!)

How are you hosting the api? Can you reach it via curl localhost:3456/apu/v1/info?

OKAY! We got it!

Realizing that I should be able to curl from the command line let me test if the backend was up and running - and it was not. When I changed the directory in the system service config, I had left out a /vikunja so my service was trying to start the directory instead of the binary. :grimacing:

Fixed that and then curl immediately worked and the front-end works perfectly. Thank you again for the help!!!

1 Like

Glad you figured it out!