"missing or malformed jwt" in Docker on Synology #2071
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#2071
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
I have Vikunja running in Docker on Synology. Now for already 4 weeks flawlessly and without errors, so I thought: Today I noticed that I get the error {"message":"missing or malformed jwt"} when copying the URL.
Comparable to these operations:
https://community.vikunja.io/t/click-on-copy-url-returns-error/773
https://kolaente.dev/vikunja/frontend/issues/2289
the YAML is this:
`version: '3'
services:
db:
image: mariadb:10
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
environment:
MYSQL_ROOT_PASSWORD: xxxxxxxxxxxxxxx
MYSQL_USER: xxxxxxxxxxxxxxxxxxx
MYSQL_PASSWORD: xxxxxxxxxxxxx
MYSQL_DATABASE: xxxxxxxxxxxxxxx
volumes:
- /volume1/docker/mariadb:/var/lib/mysql
restart: unless-stopped
api:
image: vikunja/api:latest
environment:
VIKUNJA_DATABASE_HOST: db
VIKUNJA_DATABASE_PASSWORD: xxxxxxxxxxxxxx
VIKUNJA_DATABASE_TYPE: mysql
VIKUNJA_DATABASE_USER: xxxxxxxxxxxxxxxx
VIKUNJA_DATABASE_DATABASE: xxxxxxxxx
VIKUNJA_SERVICE_JWTSECRET: 6xxxxxxxxxxxxxxxxxxxxxxxx1
VIKUNJA_SERVICE_FRONTENDURL: https://vikunja.xxxx.com/
VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
VIKUNJA_SERVICE_ENABLEUSERDELETION: false
VIKUNJA_SERVICE_ENABLETASKATTACHMENTS: true
VIKUNJA_SERVICE_ENABLEREGISTRATION: false
VIKUNJA_SERVICE_ENABLELINKSHARING: true
VIKUNJA_DEFAULTSETTINGS_DISCOVERABLE_BY_NAME: true
VIKUNJA_DEFAULTSETTINGS_WEEK_START: 1
VIKUNJA_SERVICE_ENABLEEMAILREMINDERS: 1
VIKUNJA_MAILER_FORCESSL: 1
VIKUNJA_MAILER_ENABLED: 1
VIKUNJA_MAILER_HOST: xxx
VIKUNJA_MAILER_PORT: 465
VIKUNJA_MAILER_USERNAME: xxx
VIKUNJA_MAILER_PASSWORD: xxx
ports:
- 3456:3456
volumes:
- /volume1/docker/vikunja/files:/app/vikunja/files
depends_on:
- db
restart: unless-stopped
frontend:
image: vikunja/frontend
ports:
- 4321:80
environment:
VIKUNJA_API_URL: https://vikunjaapi.xxx.com/api/v1
restart: unless-stopped`
Can someone help me?
Vikunja Frontend Version
0.21.0
Vikunja API Version
v0.21.0
Browser and version
Firefox, Edge, on PC & Android
Can you reproduce the bug on the Vikunja demo site?
Yes
Screenshots
No response
Which URL did you copy?
The attachments i mean, i uploaded the picture.
This works as intended.
The attachments are only available with an api token (jwt or persistent token). You can copy the URL and use it in an image tag in the editor and it will resolve the attachment and show the image. That's why there is a button to copy the URL.
This works as intended, just not for me.
The attachments are only available with an api token (jwt or persistent token). -> I understood is also configured in the .yaml this way with
VIKUNJA_SERVICE_JWTSECRET: 123456randompassword
.You can copy the URL and use it in an image tag in the editor, then the attachment will be resolved and the image will be displayed. For this reason there is a button to copy the URL. --> This is the one I want to use. To be very precise, I copy the URL_Link and paste it in the comment field. If I then click on the blue highlighted link (e.g. 22) in the comment field, the jwt error occurs in a new Tab.
In the meantime the container was reconfigured a dozen times. also according to different instructions like https://mariushosting.com/how-to-install-vikunja-on-your-synology-nas/. or with different DB like mariaDB or PostgreSQL.
Also the last version with "unstable" was tried and returns the error message "missing, malformed, expired or otherwise invalid token provided".
the FRONTENDURL goes to
tasks.randomname.synology.com
and the API goes toapi.randomname.synology.com
Could it have something to do with this?
Again, this is working as intended. Reconfiguring the container or trying different databases won't change how it works.
The frontendurl is unrelated to this.