S3: add NetApp StorageGrid CORS configuration details

[Samk13]

❤️ Thank you for your contribution!

Description

• Added instructions for configuring CORS in NetApp StorageGrid
  to enable file uploads and previews.
• Applying S3 configs seems to not be sufficent for StorageGrid

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've targeted the master branch.
• If this documentation change impacts the current release of InvenioRDM, I will backport it to the production branch following approval or indicate to a maintainer that it should be backported.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[m6121]

We had the same problem and provided the following PR: #867 However, based on our testing, such extensive permissions were not necessary. Can anyone verify this?

[Samk13]

Thanks for the cross-reference @m6121

To clarify: the config in your PR is correct for AWS S3, which is more permissive and doesn’t require declaring every method/header explicitly for multipart uploads. Having said that, StorageGrid behaves differently; it enforces stricter CORS validation and fails multipart/pre-signed upload flows unless all relevant methods and headers (e.g., HEAD, POST, DELETE, ETag) are explicitly allowed.

So your configuration is valid for AWS, and the expanded example here is needed for StorageGrid and similar S3-compatible backends. We'll keep both documented so users on different platforms have clear guidance.

Happy to hear others’ experiences as well.

[m6121]

Hi @Samk13 Actually, we also use Netapp Storagegrid and failed in enabling multipart upload due to the missing permissions. However, instead of enabling all methods, we tried to find a working solution which was the result in our PR (just adapted to the existing AWS configuraiton style). This setup seems to work in our tests with our netapp storage. However, we are not exactly sure, if the other methods in this PR HEAD, POST and DELETE are also needed.

[Samk13]

Interesting, thanks for the details! I'll check with our DevOps team on whether those extra methods were required in our setup or if a narrower rule set worked for us too.
Good to compare notes.

[m6121]

That's great. We are also not sure whether there are other side-effects of these more restrictive rules. Looking forward to your feedback.

[lindhe]

I'll check with our DevOps team on whether those extra methods were required in our setup or if a narrower rule set worked for us too.

Hello, I'm the DevOps team! ✋ 😅

I need to double check something in our proxy first, just so I don't confuse matters more than necessary. BRB.

[lindhe]

Confusingly, we have two different policies in place. I'll have to experiment next week to verify what's really required.

[fenekku]

v14 cleanup

@lindhe / @Samk13 were things finally unconfused and what is really required determined 😄 ? Adjust the PR accordingly or let us know it's all good so we can merge for v14.

[tmorrell]

I believe the CORS config is only needed if you're using uppy as the uploader, and it might also be required for AWS. So while this help info is needed, we want to double check the scope.

[lindhe]

v14 cleanup

@lindhe / @Samk13 were things finally unconfused and what is really required determined 😄 ? Adjust the PR accordingly or let us know it's all good so we can merge for v14.

I'm afraid it has not been unconfused yet. We depend on an external proxy for applying the CORS. It is just a temporary work-around, so I was hoping we would get rid of it a long time ago and thus become unconfused. Alas, nothing is so permanent as a temporary solution.

In my opinion, we should close this PR until we are able to try it out with StorageGRID's built-in CORS handler. Otherwise, we can only test it with the proxy solution and then we risk creating misleading docs.

[fenekku]

@lindhe Got it. I will remove it from v14 critical path and this can be revisited later. Thanks for that.