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

[sivakrishnamattadev]

Is there an existing issue for this?

• [x] 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

[castrapel]

@mguptahub I think this is because the K8s ingress created through our helm-values.yml are http-only by design. This is because TLS is terminated by a GCP load balancer. The reason we are doing it this way is because Google supports a feature called Identity Aware Proxy, which lets us protect services behind the load balancer, require google authentication, and prevent non-company users from getting past the load balancer.

User -> https://plane.domain -> GCP Load Balancer (TLS termination with cloud armor and waf) -> ingress-nginx (HTTP) -> plane service

Here is the relevant snippet from our helm values:

ingress:
  enabled: true
  minioHost: ''
  rabbitmqHost: ''
  ingressClass: 'nginx'
  ingress_annotations: {
    "nginx.ingress.kubernetes.io/proxy-body-size": "15m",
  }

ssl:
  createIssuer: false
  issuer: http # Allowed : cloudflare, digitalocean, http
  token: '' # not required for http
  server: https://acme-v02.api.letsencrypt.org/directory
  email: [email protected]
  generateCerts: false

Everything else with the app appears to work so far, with the exception of file uploads.

[akshat5302]

Hey @castrapel, have you tried adding the following annotation to your ingress-nginx?

nginx.ingress.kubernetes.io/configuration-snippet: |
  proxy_set_header X-Forwarded-Proto $scheme;

If not, please give it a try and see if it helps.

[castrapel]

@akshat5302 That results in an infinite redirect. Since the request from the GCP load balancer to the K8s ingress is always "http", nginx always attempts to redirect the user to the TLS endpoint. This solution doesn't work when TLS is terminated by an external load balancer.

[akshat5302]

Hi, @castrapel. We're working on this and will include a fix in our upcoming releases.

[akshat5302]

Hey @castrapel, we've fixed this issue in our latest community release. If you're using the community version of the Plane Helm chart, please set the minio_endpoint_ssl environment variable to true. Let us know if this resolves the issue!

[castrapel]

Thank you - We're using the plane/plane-enterprise helm chart. Please let me know when that one is updated and I'll give it a try!

[akshat5302]

Sure! @castrapel will push a fix for the Enterprise Edition in our upcoming release. We’ll update you here as soon as the fix is available in the latest version.

[akshat5302]

Hi @castrapel,

We've pushed the changes to Plane Enterprise Edition. Could you please set the minio_endpoint_ssl environment variable to true and verify if everything works as expected?

Thanks!

[akshat5302]

Hi @castrapel, did the solution work for you? If so, please let me know if it's okay to close this issue.

[castrapel]

Hi @akshat5302 , feel free to close the issue. Thank you.