Problème de cookies signé par Cloudfront, obtention de 403

Nous avons utilisé CloudFront pour stocker des URL d'images et utiliser des cookies signés pour fournir un accès uniquement via notre application. Sans les cookies signés, nous sommes en mesure d'accéder au contenu, mais après avoir activé les cookies signés nous obtenons HTTP 403.Problème de cookies signé par Cloudfront, obtention de 403

ci-dessous la configuration/les cookies nous envoyons:

Cookies aller à la demande:

CloudFront-Expires: 1522454400
CloudFront-Key-Pair-Id: xyz...
CloudFront-Policy: abcde...
CloudFront-Signature: abce...

Voici notre politique de CloudFront:

{ 
    "Statement": [ 
     { 
     "Resource":"https://*.abc.com/*", 
     "Condition":{ 
      "DateLessThan":{"AWS:EpochTime":1522454400} 
     } 
     } 
    ] 
}

Le domaine du cookie est .abc.com, et le chemin des ressources est https://*.abc.com/*. Nous utilisons CannedPolicy pour créer des cookies CloudFront.

Pourquoi cela ne fonctionne-t-il pas comme prévu?

Source

2017-08-14 SANDIP

Consultez la documentation de nouveau

Il n'y a que trois témoins, le dernier étant soit CloudFront-Expires pour une politique en conserve, ou CloudFront-Policy pour une politique personnalisée.

Nous utilisons CannedPolicy

Une politique en conserve a une ressource implicite de *, donc un énoncé de politique en boîte ne peut pas avoir un Resource explicite, de sorte que vous êtes en fait à l'aide d'une stratégie personnalisée. Si tout le reste est correctement implémenté, votre solution peut simplement être de supprimer le cookie CloudFront-Expires, qui n'est pas utilisé avec une stratégie personnalisée.

Les politiques «conservées» (embouteillées, jugulées, préemballées) sont utilisées dans les cas où la seule information unique dans la politique est l'expiration. Leur avantage est qu'ils nécessitent une bande passante légèrement moindre (et font des URL plus courtes lors de la création d'URL signées). Leur inconvénient est qu'ils sont des wildcards par conception, ce qui n'est pas toujours ce que vous voulez.

Source

2017-08-14 13:34:59

Michael, nous avons juste besoin d'empêcher l'accès direct du contenu avec l'URL, nous avons donc pensé à utiliser des cookies signés, de sorte que le contenu soit accessible uniquement par l'application. De plus, nous n'utilisons que des polices en boîte. Si nous n'envoyons que trois cookies: CloudFront-Expires: 1522454400, CloudFront-Key-Pair-Id: xyz ..., CloudFront-Signature: abce ... nous obtenons toujours 403. code: this.signedCookies = CloudFrontCookieSigner.getCookiesForCannedPolicy ( \t \t \t \t Protocole.https, this.domaine, privateKeyFile, this.resourcePath, this.keyPairId, expiresOn); – SANDIP

J'ai la solution. Notre exigence était un accès générique. CloudFrontCookieSigner.getCookiesForCustomPolicy(this.resourcePath,pk,this.keyPairId,expiresOn,null,"0.0.0.0/0");

where resource path = https+ "distribution name" + /* 
     activeFrom = it is optional so pass it as null 
     pk = private key (few api also take file but it didn't work, so get the private key from file and use above function)

nous voulons accéder à tous les contenus sous la distribution, la politique en boîte ne permet pas générique. Nous l'avons donc changé en politique personnalisée et cela a fonctionné.

Source

2017-08-21 14:16:33 SANDIP

Problème de cookies signé par Cloudfront, obtention de 403

Répondre

Questions connexes