Amplify-ios: Storage prefixes configurable

[baillyjamy]

Is your feature request related to a problem? Please describe.
Hello, I would like to use amplify-ios lib to retreive S3 object from existing S3 but the prefix "/public" is forced. It is therefore impossible for me to find my files.

Describe the solution you'd like
Can you make the prefixes configurable? This would make life easier for existing projects.

Additional context
I see that I can add "pluginOptions" in my request. Maybe I can change/delete the prefix through this? But I can't find the documentation that lists the possible key/values

[diegocstn]

hi @baillyjamy ,
thanks for reaching out.
The Amplify Storage plugin currently support three different access levels: public, protected, private, defined by the StorageAccessLevel enum.

Each storage request accepts an options argument based on its type.
For example, below a list request:

let listOptions = StorageListRequest.Options(accessLevel: .private)
Amplify.Storage.list(options: listOptions) { ... }

Unfortunately we don't currently support fully customizable prefixes, but I'll mark this as a possible enhancement and discuss it the team.

[baillyjamy]

Thank you for taking the time to read me and consider my request.

I would like to give you some additional feedback.
I don't think it's a good idea to force people who want to use an aws functionality on mobile to use the Amplify workflow if it's very restrictive, for example in my case, I want to access an S3 instance created without amplify so it doesn't necessarily respect its rules (rules that I don't dispute) but I use Cognito to give access to my S3.
I could use aws-sdk-ios but it's a bad idea to reinvent the wheel. Amplify facilitates Cognito authentication and renews it. Also, all aws-sdk-ios documentation refers to Amplify.
So even if I want to re-implement the Cognito authentication system and connect to my S3 with aws-sdk-ios, it's difficult without documentation.

Well, I may be a lazy guy but I tried to bypass Amplify and reinvent the wheel for Android, it was not a good idea. I'd like to avoid starting again here ^^

What I'm trying to say is that either we need an Amplify that is more customisable and less restrictive, or we need an aws-sdk-ios that is better documented and less in the shadows.
Or maybe I didn't understand anything about Amplify? In that case I'd like some help to find out how you would solve my case.

Thanks for reading, my english is not very good, it's just a feedback, not a request. It's not arrogant.

[richardmcclellan]

For reference, this has been requested for Android as well: https://github.com/aws-amplify/amplify-android/issues/910

[baillyjamy]

Hello, I'm coming back to you to see if you're going to add this feature or not. And if so, do you have an idea of when?
On my side I have to make a choice if I use Amplify or not and I have to move forward on the subject of retrieving my S3 objects. Your answer will help me to make a decision.

[baillyjamy]

Hello, being unanswered, I take the liberty of asking you again to find out what you are going to do.

[saravr]

These prefixes should be configurable - developers/end users should decide what's best for them. Can this be request be prioritized?

[danquack]

@diegocstn The JS client also had this issue and there appears to be a workaround. Wondering if something similar could happen for iOS https://github.com/aws-amplify/amplify-js/issues/332#issuecomment-602606514

[samulacrum]

Yeah, this entirely breaks our use case - and we cannot re-configure our existing backend setup just to support the forced prefixes.

Please make this configurable - and make it more explicit in the documentation that this behavior occurs.

[lawmicha]

A discussion on discord, the developer wants to completely remove the prefix. The flexibliity to configure custom prefixes should allow configuring "empty" or no prefix for certain levels.

[baillyjamy]

Still no news for this feature? I don't understand why this feature is implemented for the js lib and not for ios.