Explanation
Pre-authenticated requests provide a way to let users access a bucket or an object without having their own credentials, as long as the request creator has permissions to access those objects. For example, you can create a request that lets an operations support user upload backups to a bucket without owning API keys. Or,you can create a request that lets a business partner update shared data in a bucket without owning API keys.
When you create a pre-authenticated request, a unique URL is generated. Anyone you provide this URL to can access the Object Storage resourcesidentified in the preauthenticated request, using standard HTTP tools like curl and wget.
Understand the following scope and constraints regarding pre-authenticated requests:
Users can't list bucket contents.
You can create an unlimited number of pre-authenticated requests.
There is no time limit to the expiration date that you can set.
You can't edit a pre-authenticated request. If you want to change user access options in response to changing requirements, you must create a new preauthenticated request.
The target and actions for a pre-authenticated request are based on the creator's permissions. The request is not, however, bound to the creator's account login credentials. If the creator's login credentials change, a pre-authenticated request is not affected.
You cannot delete a bucket that has a pre-authenticated request associated with that bucket or with an object in that bucket.
Understand the following scope and constraints regarding public access:
Changing the type of access is bi-directional.You can change a bucket's access from public to private or from private to public.
Changing the type of access doesn't affect existing pre-authenticated requests. Existing pre-authenticated requests still work.