Stream s3 stored background through planka #606

New Issue

OVERLORD · 2026-02-04T20:32:04+03:00

OVERLORD commented

2026-02-04 20:32:04 +03:00

Originally created by @Alexsaphir on GitHub (Nov 14, 2024).

Is this a feature for the backend or frontend?

Backend

What would you like?

As for the attachments, could the background assets be re-streamed through the server?
Thanks

Why is this needed?

Remove the need to expose publicly assets.

Other information

No response

Originally created by @Alexsaphir on GitHub (Nov 14, 2024). ### Is this a feature for the backend or frontend? Backend ### What would you like? As for the attachments, could the background assets be re-streamed through the server? Thanks ### Why is this needed? Remove the need to expose publicly assets. ### Other information _No response_

OVERLORD commented

2026-02-04 20:32:08 +03:00

@meltyshev commented on GitHub (Nov 14, 2024):

Hi! Did you mean project backgrounds? I thought it might not make much sense because backgrounds without S3 are also accessible via a link, even without a valid session. If we're talking about attachments and their previews, they're re-streamed through the Planka server, and direct access can be restricted using S3's ACL.

@meltyshev commented on GitHub (Nov 14, 2024): Hi! Did you mean project backgrounds? I thought it might not make much sense because backgrounds without S3 are also accessible via a link, even without a valid session. If we're talking about attachments and their previews, they're re-streamed through the Planka server, and direct access can be restricted using S3's ACL.

OVERLORD commented

2026-02-04 20:32:13 +03:00

@Alexsaphir commented on GitHub (Nov 14, 2024):

Yes, talking about the project backgrounds.
I use minio as a s3 server and by default the assets are private. If you prefer it that way I can define the proper ACL on my side, but letting Planka manage the access seems better, from my point of view. It's a preference, I would understand perfectly if it's not something that you want to do.

A solution could be to use S3-presigned URL, the bucket can be fully private while letting Planka grant time-limited access. Moreover, this could be also used for the attachments and their previews, removing the need to stream them and just generating the URL on the fly when permissions are met.

(Sidenote: those pre-signed URL can be used to download content but also upload, removing the need to store the content with Planka temporarily)

Reference: AWS S3 Documentation

@Alexsaphir commented on GitHub (Nov 14, 2024): Yes, talking about the project backgrounds. I use minio as a s3 server and by default the assets are private. If you prefer it that way I can define the proper ACL on my side, but letting Planka manage the access seems better, from my point of view. It's a preference, I would understand perfectly if it's not something that you want to do. A solution could be to use S3-presigned URL, the bucket can be fully private while letting Planka grant time-limited access. Moreover, this could be also used for the attachments and their previews, removing the need to stream them and just generating the URL on the fly when permissions are met. (Sidenote: those pre-signed URL can be used to download content but also upload, removing the need to store the content with Planka temporarily) Reference: [AWS S3 Documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)

OVERLORD commented

2026-02-04 20:32:19 +03:00

@meltyshev commented on GitHub (Nov 15, 2024):

Using a fully private bucket and re-streaming background images or using presigned URLs both have their downsides:

Re-streaming: The main disadvantage is that the Planka server remains involved throughout the download process, which can slow down performance and increase server load. For non-sensitive data such as project backgrounds, re-streaming is unnecessary because direct access is faster and more efficient, especially when session verification isn't needed.

Presigned URLs: You can't store presigned URLs in the database, as they are time-limited. This means the server must request S3 to generate a new URL each time an image is accessed. While this approach might reduce server load compared to re-streaming (as you can simply redirect to the new URL), it still adds complexity and extra load, making it less practical than using direct links.

When I reviewed the PR and considered secure attachment management, I looked at how other services handle this. Typically, re-streaming is used for attachments to ensure session validation and access control, whereas less sensitive files, such as avatars and backgrounds, are made available via direct links.

@meltyshev commented on GitHub (Nov 15, 2024): Using a fully private bucket and re-streaming background images or using presigned URLs both have their downsides: **Re-streaming:** The main disadvantage is that the Planka server remains involved throughout the download process, which can slow down performance and increase server load. For non-sensitive data such as project backgrounds, re-streaming is unnecessary because direct access is faster and more efficient, especially when session verification isn't needed. **Presigned URLs:** You can't store presigned URLs in the database, as they are time-limited. This means the server must request S3 to generate a new URL each time an image is accessed. While this approach might reduce server load compared to re-streaming (as you can simply redirect to the new URL), it still adds complexity and extra load, making it less practical than using direct links. When I reviewed the PR and considered secure attachment management, I looked at how other services handle this. Typically, re-streaming is used for attachments to ensure session validation and access control, whereas less sensitive files, such as avatars and backgrounds, are made available via direct links.

OVERLORD commented

2026-02-04 20:32:23 +03:00

@meltyshev commented on GitHub (Nov 15, 2024):

Btw, I also tested S3 integration with MInIO and here is my ACL config (planka is the bucket name):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "*"
                ]
            },
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::planka/public/*"
            ]
        }
    ]
}

@meltyshev commented on GitHub (Nov 15, 2024): Btw, I also tested S3 integration with MInIO and here is my ACL config (`planka` is the bucket name): ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::planka/public/*" ] } ] } ```

OVERLORD commented

2026-02-04 20:32:31 +03:00

@cjbars commented on GitHub (Nov 18, 2024):

We can store in the database not the full url, but only the key
To create a pre-signed url we don't need to access s3, it is done on the application side.

In this way we can work with private s3 storage without using retransmission through the planka server.

@cjbars commented on GitHub (Nov 18, 2024): 1. We can store in the database not the full url, but only the key 2. To create a pre-signed url we don't need to access s3, it is done on the application side. In this way we can work with private s3 storage without using retransmission through the planka server.

OVERLORD commented

2026-02-04 20:32:41 +03:00

@meltyshev commented on GitHub (Nov 19, 2024):

In my opinion, generating presigned URLs and storing them in the database is not a good approach.

The first issue is that you always need to store the "token" in the database. For example, if you decide to migrate from storing files locally to S3, you would need to generate a token for each file and save it to the database.

The second issue comes if the S3 access_key is rotated/changed for any reason. In such cases you would need to regenerate all the "tokens" in the database.

With the current approach migration to/from S3 is pretty simple, and there is no dependency on the current access_key. The only drawback is that you need to set up a policy once to ensure proper accessibility.

Please feel free to correct me if I’m wrong.

@meltyshev commented on GitHub (Nov 19, 2024): In my opinion, generating presigned URLs and storing them in the database is not a good approach. The first issue is that you always need to store the "token" in the database. For example, if you decide to migrate from storing files locally to S3, you would need to generate a token for each file and save it to the database. The second issue comes if the S3 `access_key` is rotated/changed for any reason. In such cases you would need to regenerate all the "tokens" in the database. With the current approach migration to/from S3 is pretty simple, and there is no dependency on the current `access_key`. The only drawback is that you need to set up a policy once to ensure proper accessibility. Please feel free to correct me if I’m wrong.

OVERLORD commented

2026-02-04 20:32:49 +03:00

@Alexsaphir commented on GitHub (Nov 19, 2024):

We can store in the database not the full url, but only the key

In my opinion, generating presigned URLs and storing them in the database is not a good approach.

The key is the path to the file, you need to store them like you store the filename.

Then, because the urls are signed during the request, you use the available credentials, with a valid time of 10 minutes for example. (no rotation required)

@Alexsaphir commented on GitHub (Nov 19, 2024): > * We can store in the database not the full url, but only the key > In my opinion, generating presigned URLs and storing them in the database is not a good approach. The `key` is the path to the file, you need to store them like you store the filename. Then, because the urls are signed during the request, you use the available credentials, with a valid time of 10 minutes for example. (no rotation required)

OVERLORD commented

2026-02-04 20:32:55 +03:00

@meltyshev commented on GitHub (Nov 19, 2024):

The key is the path to the file, you need to store them like you store the filename.

Got it, so it wasn't about the signed part.

Then, because the urls are signed during the request, you use the available credentials, with a valid time of 10 minutes for example. (no rotation required)

If the server signs a URL when requesting the required static file, does this mean the server would sign the URL and then respond with a redirect to the newly signed URL? I’m a bit unclear on the purpose of this approach. If all files are ultimately publicly accessible but only through the Planka server, wouldn’t it be simpler to set a policy in S3 to allow direct access to /public?

If the server signs URLs when responding with JSON data that includes signed URLs, this could create issues since Planka is a single-page application and doesn’t require a full page refresh (e.g., when you switch between already loaded boards, they are not reloaded). After the configured valid time (e.g., 10 minutes), all signed URLs would expire, requiring users to refresh the page to retrieve new URLs. This approach seems impractical for maintaining a seamless user experience.

@meltyshev commented on GitHub (Nov 19, 2024): > The `key` is the path to the file, you need to store them like you store the filename. Got it, so it wasn't about the signed part. > Then, because the urls are signed during the request, you use the available credentials, with a valid time of 10 minutes for example. (no rotation required) If the server signs a URL when requesting the required static file, does this mean the server would sign the URL and then respond with a redirect to the newly signed URL? I’m a bit unclear on the purpose of this approach. If all files are ultimately publicly accessible but only through the Planka server, wouldn’t it be simpler to set a policy in S3 to allow direct access to `/public`? If the server signs URLs when responding with JSON data that includes signed URLs, this could create issues since Planka is a single-page application and doesn’t require a full page refresh (e.g., when you switch between already loaded boards, they are not reloaded). After the configured valid time (e.g., 10 minutes), all signed URLs would expire, requiring users to refresh the page to retrieve new URLs. This approach seems impractical for maintaining a seamless user experience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#606