Post policy

Last updated:2021-04-28 10:59:26

Policy、Signature Building Methods

Policy Building Methods


Policy is a JSON document encoded with UTF-8 and Base64, which specifies the conditions that the request must meet and is used to authenticate the content. Depending on how you design policy documents, you can use them for each upload, for each user, for all uploads, or for other designs that meet your needs.
Policy document example

	"expiration": "2015-01-01T12:00:00.000Z",
	 "conditions": [
	    ["eq","$acl", "public-read" ],
		["eq","$bucket", "mybucket" ],
	    ["starts-with", "$key", "2015/01/"]


The expiration element uses the ISO 8601 UTC date format to specify the expiration date of the policy, that is, it can only be uploaded before the specified time. Uploads after this time will be considered illegal, and KS3 will return 403. Note: the time zone is Green time (zero time zone) instead of Beijing time (East 8 zone)


The validation conditions for the uploaded content in the Policy document. Each form field you specify in the form (except KSSAccessKeyId、Signature、file、policy and bucket must be included in the condition list.

Note: all variables in the form are extended before the Policy is validated. Therefore, all condition matches should be performed for the extended fields. For example, if you set the key field to 2015/01/${filename}, the condition in your policy might be [ “starts-with”, “$key”, “2015/01/” ]。Do not enter. [ “starts-with”, “$key”, “2015/01/${filename}” ]

Element Name Description
bucket Specify the conditions that bucket must meet, support exact matching and starts-with
acl Specify the conditions that ACL must meet to support exact matching and starts-with
content-length-range Specify the minimum and maximum content length values of uploaded content (not only files, but also other form items). Range matching is supported
Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires Rest special head. Support exact match and starts-with
key Uploaded key,support exact match and starts-with
success_action_redirect, redirect The path to redirect after a successful upload.Support exact match and starts-with
success_action_status The status code returned after a successful upload (in the case of no success_action_redirect, redirect), only supports exact matching
Other Form Items Starting with x-kss-meta User metadata. Supports exact matching and starts-with
Form items other than KSSAccessKeyId、Signature、file、policy The KS3 server will not process these form items. But it must be included in the policy document. Support exact match and starts-with

Condition Matching Rule

Matching Rule Example
Exact matching Specifies that ACL must be equal to public-read。{“acl”: “public-read” } or [ “eq”, “$acl”, “public-read” ]
Starts with The specified key must start with 2015 / 01 /.[“starts-with”, “$key”, “2015/01/”]
Wildcard Specify that success_action_redirect can be any value (Note: success_action_status does not support wildcard).[“starts-with”, “$success_action_redirect”, “”]
Specify Content-Length Range Specifies that the Content-Length range of the uploaded content (not only files, but also other form items) is 1048579-10485760.[“content-length-range”, 1048579, 10485760]

Character Escape

The characters in the following table must be converted in the Policy document

Escape Character Description
\\ Backslash
$ Dollar Symbol
\b Backspace Key
\f Page Change
\n New Construction Bank
\r Enter
\t Horizontal Tab
\v Vertical Tab
\uxxxx Unicode Character

Signature Building Methods

For authenticated Post requests, the HTML form must contain Policy and Signature information.
Policy controls which values are allowed in the request.
The specific process of calculating Signature is as follows:

  1. Create a UTF-8 encoded Policy document. See the Policy building method for details.
  2. Base64 code the policy, whose value is the value that the policy form field should fill in, and use the value as the String To Sign.
    3)Signature = Base64(HMAC-SHA1(YourSecretKey, UTF-8-Encoding-Of(StringToSign ) ) );

Did you find the above information helpful?

Mostly Unhelpful
A little helpful
Very helpful

What might be the problems?

  • Insufficient
  • Outdated
  • Unclear or awkward
  • Redundant or clumsy
  • Lack of context for the complex system or functionality

More suggestions


Please give us your feedback.


Thank you for your feedback.