Question

我正在寻找概念层面的答案。因此，请不要简单地提供aws文档的链接作为答案。

生成预设政策的方式

@staticmethod
def _canned_policy(resource, expires):
    """
    Creates a canned policy string.
    """
    policy = ('{"Statement":[{"Resource":"%(resource)s",'
              '"Condition":{"DateLessThan":{"AWS:EpochTime":'
              '%(expires)s}}}]}' % locals())
    return policy

同一个库

生成自定义政策的方式

@staticmethod
def _custom_policy(resource, expires=None, valid_after=None, ip_address=None):
    """
    Creates a custom policy string based on the supplied parameters.
    """
    condition = {}
    # SEE: http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/RestrictingAccessPrivateContent.html#CustomPolicy
    # The 'DateLessThan' property is required.
    if not expires:
        # Defaults to ONE day
        expires = int(time.time()) + 86400
    condition["DateLessThan"] = {"AWS:EpochTime": expires}
    if valid_after:
        condition["DateGreaterThan"] = {"AWS:EpochTime": valid_after}
    if ip_address:
        if '/' not in ip_address:
            ip_address += "/32"
        condition["IpAddress"] = {"AWS:SourceIp": ip_address}
    policy = {"Statement": [{
                 "Resource": resource,
                 "Condition": condition}]}
    return json.dumps(policy, separators=(",", ":"))

在我看来，预制策略本质上是一种自定义策略，但属性较少。

如果是正确的观察，那为什么需要两种不同的不同类政策？

Answer 1

是的，预制策略只能传达自定义策略属性的特定子集，但两者之间的区别更为重要。

当您使用预制（预定义）策略时，生成的预设策略文档的内容是如此具有确定性和可预测性 - 从请求的元素本身 - 策略文档甚至不需要与请求一起发送到CloudFront。

相反，它是在本地生成的，因此您可以对其进行签名，但随后将其丢弃。服务器根据请求参数生成相同的文档，并验证签名。

相比之下，使用自定义策略时，策略文档本身将与URL中的&Policy=中的base-64编码请求一起发送。这使得URL更长，因为必须一起发送策略文档，但现在允许策略文档本身包含不能通过简单检查从请求中简单推断的元素。

然后，预制策略（至少在某种程度上）更“轻量级” - 较短的URL意味着请求中包含的字节更少，使用它们所需的处理更少，但它们的灵活性低于自定义策略。

比较矩阵：http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html

固定策略和自定义策略之间有什么区别？

1 个答案: