[bug]: Unable to upload files / attachements after upgrade v0.24.1

[sivakrishnamattadev]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

I recently upgraded my self-hosted Plane Community Edition to the latest version v24.1 and migrated the database to an external PostgreSQL instance. However, after the upgrade and migration, I am unable to upload attachments.

Issue Details:

• I noticed errors in the console logs and network tab, specifically related to file uploads.
• The upload requests seem to be going to HTTP instead of HTTPS.
• I am using the default MinIO setup from Plane, with only the database migrated to an external PostgreSQL instance.

Troubleshooting Steps Taken:

• I checked existing issues related to NGINX and upload configurations, but changes to NGINX are not reflecting.
• Even after restarting Docker, the configurations seem to revert to the old values.
• I suspect this issue might be due to Plane resetting configurations after the upgrade.

Request for Assistance:

• Could you please confirm if this is a known issue after upgrading to v24.1?
• Any guidance on fixing the upload URL redirecting to HTTP instead of HTTPS would be greatly appreciated.
• Is there any additional configuration required for MinIO, NGINX, or Plane storage settings after migrating the database?

Looking forward to your support.

Steps to reproduce

1. Go to Projects
2. Click on any existing issue
3. Go to add new comment
4. try to add/paste one image
5. Image will display in blur mode
6. Image will not upload end up with console errors.
7. Error Following:

Something went wrong
push.518.window.console.error @ 2364-8788a2017886c784.js:1
8521-8ba9b5bba2500f7f.js:1 Mixed Content: The page at 'https://abcxxx.com/amg/projects/6502cf55-fd6e-4a26-ad40-81f8c21f2ec2/issues/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://abcxxx.com/uploads'. This request has been blocked; the content must be served over HTTPS.
(anonymous) @ 8521-8ba9b5bba2500f7f.js:1
xhr @ 8521-8ba9b5bba2500f7f.js:1
es @ 8521-8ba9b5bba2500f7f.js:1
_request @ 8521-8ba9b5bba2500f7f.js:1
request @ 8521-8ba9b5bba2500f7f.js:1
(anonymous) @ 8521-8ba9b5bba2500f7f.js:1
(anonymous) @ 8521-8ba9b5bba2500f7f.js:1
post @ error-9eb3569ce6e56f54.js:1
uploadFile @ 2572-0879269fc9ed108d.js:1
(anonymous) @ 1692-f66e11ddf642f09c.js:1
Promise.then
uploadProjectAsset @ 1692-f66e11ddf642f09c.js:1
uploadCommentAsset @ 1692-f66e11ddf642f09c.js:1
uploadFile @ 1692-f66e11ddf642f09c.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
ew @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 2f7efde8-fcebd67c055a7f47.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
ew @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
(anonymous) @ 4524-9b32e18f1e9c470b.js:1
aW @ 618f8807-b5255caf8e399037.js:1
oe @ 618f8807-b5255caf8e399037.js:1
-- so many same lines --
-- so many same lines --
ol @ 618f8807-b5255caf8e399037.js:1
1692-f66e11ddf642f09c.js:1 Error in uploading comment asset: undefined
4524-9b32e18f1e9c470b.js:1 Error: Asset upload failed. Please try again later.
at Object.uploadCommentAsset (1692-f66e11ddf642f09c.js:1:418976)
at async uploadFile (1692-f66e11ddf642f09c.js:1:448319)

Environment

Production

Browser

Other

Variant

Self-hosted

Version

v0.24.1

[akshat5302]

Hi @sivakrishnamattadev, could you please update your nginx configuration to include the headers mentioned in the external reverse proxy configuration

[sivakrishnamattadev]

Following is the ngINX.conf inside the container.

events {
}

http {
    sendfile on;

    server {
        listen 80;
        root /www/data/;
        access_log /var/log/nginx/access.log;

        client_max_body_size 5242880;

        add_header X-Content-Type-Options    "nosniff" always;
        add_header Referrer-Policy           "no-referrer-when-downgrade" always;
        add_header Permissions-Policy        "interest-cohort=()" always;
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        add_header X-Forwarded-Proto         "$scheme";
        add_header X-Forwarded-Host          "$host";
        add_header X-Forwarded-For           "$proxy_add_x_forwarded_for";
        add_header X-Real-IP                 "$remote_addr";

        location / {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://web:3000/;
        }

        location /api/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://api:8000/api/;
        }

        location /auth/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://api:8000/auth/;
        }

        location /god-mode/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://admin:3000/god-mode/;
        }

        location /live/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://live:3000/live/;
        }

        location /spaces/ {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://space:3000/spaces/;
        }

        location /uploads {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://plane-minio:9000/uploads;
        }
    }
}

the following part i did tried to update...

        location /uploads {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Ssl on;
            proxy_pass http://plane-minio:9000/uploads;
        }

I did update the uploads as above, and restart the docker, the changes are defaulted to followed.

        location /uploads {
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $http_host;
            proxy_pass http://plane-minio:9000/uploads;
        }

Could you please guide me more detailed how do I update? is there any external ngINX.conf impacting?

[sivakrishnamattadev]

and it was working flawless with v0.21.1., why this issue coming with the new update?

[akshat5302]

Hey @sivakrishnamattadev

Have you set up any external reverse proxy? If yes, then based on the type of proxy server, you might need to make the required changes. If it is nginx then add

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;

You do not need to change anything in the nginx.conf present inside the container.

[castrapel]

I am having the same problem. I am running Plane in GKE. I use a Google Application Load Balancer to terminate TLS and handle Google authentication. Requests are then routed to an http load balancer (an nginx ingress). Traffic within the GKE cluster is http-only, so automatically upgrading connections to https won't work for us. Instead, it would be nice if the frontend would post to a relative URL instead of trying to infer if the website is http or https. Is it not possible to just have it POST. to /uploads?

[sivakrishnamattadev]

I have changed my external AVI configuration, which redirects this mixed protocols, which solved my problem.

But my question was, while it was working flawless without changing the AVI configuration, it should work after the update?

Ok, now the second point, why I can’t modify the ngINx.config ? Provide us proper guidelines for the modification of ngINX.conf, Appreciate your help!

[mguptahub]

Hello @sivakrishnamattadev / @castrapel

I see @sivakrishnamattadev is deploying using setup.sh / docker-compose behind external reverse proxy

While, @castrapel is deploying using Helm Charts.

We need to handle both cases very differently.

@akshat5302 has already suggested solution to apply a fix required for external reverse proxy

@castrapel - I would be interested to know the case why the uploads is going to http instead of https. The helm deployment creates all the required routes under same ingress where the certificate is attached.

Check the request call