Stream s3 stored background through planka

[Alexsaphir]

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

[meltyshev]

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.

[Alexsaphir]

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

[meltyshev]

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]

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/*"
            ]
        }
    ]
}

[cjbars]

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.

[meltyshev]

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.

[Alexsaphir]

• 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)

[meltyshev]

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.