Image attachments displaying duplicates

Bug
1

Uploading an image as a task attachment has resulted in the image displaying multiple times when viewing the task:

image
image467×626 49.4 KB

After deleting just one of them, an attempt to delete any of the others results in a message in a little red box (sorry but it will only let me embed a single image) that says:

Error: Request failed with status code 404 The task attachment does not exist.

Logging out and back in to either the desktop app or the web interface doesn’t change anything - these rogue entries are still shown.

2

Here we go…

image

3

I’ve just tried deleting 3 of the entries and all three are showing the same ID’s in the log:

vikunja[19115]: #033[31m2021-11-11T14:45:05.159004315Z: ERROR#011▶ handler/DeleteWeb 1c160#033[0m Task attachment does not exist [TaskID: 62, AttachmentID: 2, FileID: 0]
vikunja[19115]: #033[31m2021-11-11T14:45:07.393272806Z: ERROR#011▶ handler/DeleteWeb 1c174#033[0m Task attachment does not exist [TaskID: 62, AttachmentID: 2, FileID: 0]
vikunja[19115]: #033[31m2021-11-11T14:45:09.380268423Z: ERROR#011▶ handler/DeleteWeb 1c188#033[0m Task attachment does not exist [TaskID: 62, AttachmentID: 2, FileID: 0]

4

The FileID: 0 part looks odd.

Does this happen every time you upload an attachment?
Can you reproduce this on try?

5

No I can’t. Going back to the tasks that were showing rogue entries… they’ve now gone. Possibly some strange caching issue. I’ve just tried attaching a file to another task. It shows 1 attachement. If I come back out of the task then click on it, it shows 2. Out and back in again and there’s 3… and so on. So I’m guessing the first time I delete it, it works - after that it fails because the attachments aren’t actually really there even though they’re still displaying. I have a nginx reverse proxy in front of it so maybe I’ll take a look in there

6

I generally use nginx as a security layer and serve any http content up from apache. The relevant location blocks in nginx are as follows:

    location ~* ^/(api|dav|\.well-known)/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://localhost:3456;
    client_max_body_size 20M;
    }

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_max_temp_file_size 0;
        proxy_buffers 16 16k;  
        proxy_buffer_size 16k;
        proxy_pass http://127.0.0.1:8080;
    }

and apache 2 is as follows:

    RewriteEngine On
 	RewriteRule ^\/?(favicon\.ico|assets|audio|fonts|images|manifest\.webmanifest|robots\.txt|sw\.js|workbox-.*|api|dav|\.well-known) - [L]
    RewriteRule ^(.*)$ /index.html [QSA,L]
    <Directory /var/www/tasks.example.com/html>
        Options -Indexes +FollowSymLinks +MultiViews
        AllowOverride All
        Require all granted

    </Directory>

    SetEnvIf X-Forwarded-Proto "https" HTTPS=on

    RemoteIPHeader X-Forwarded-For
    RemoteIPTrustedProxy 127.0.0.1

Can you spot anything wrong here? Other than this issue it all appears to be working ok.

7

I’m not sure if this is related to using apache and nginx the way you do. It looks like you used the apache2 config from the proxy + frontend host example. Try this one which is for hosting just the frontend.

What version are you using?

8

Of vikunja? I only downloaded it last week so I imagine the most recent unless something else has been released since. I’ll try tinkering with that apache config and report back.

9

And what version did you download?

You can check this in the about dialog in the frontend.

10

Both frontend and API are v0.18.1

1 Like