2017-08-21 8 views
0

私は、私たちのサービスの1つにLambda @ Edgeを追加しようとしています。目標は、特定の値のURLを正規表現し、承認を保証するためにそれらをヘッダー値と比較することです。値が存在する場合はそれが比較され、拒否された場合は403がユーザーにすぐに返されます。比較された値が一致するか、urlに特定の値が含まれていない場合、要求は許可された要求として継続されます。CloudFrontのLambda @ Edge認証を実装する

当初私はこれが「視聴者要求」イベントで発生すると考えていました。 SOに関する投稿やコメントの中には、「起点リクエスト」がこの小切手の理想的なものであることが示唆されています。しかし、今私は、CFエンドポイントのドキュメントの例題を試してみようとしていますが、期待した結果が見られません。コードは以下の通りです:

'use strict'; 
exports.handler = (event, context, callback) => { 
    const request = event.Records[0].cf.request; 
    request.headers["edge-test"] = [{ 
     key: 'edge-test', 
     value: Date.now().toString() 
    }]; 

    console.log(require('util').inspect(event, { depth: null })); 

    callback(null, request); 
}; 

私はCloudWatchの内部に記録された値とのリクエストで新しいヘッダー値が存在すべきであることを期待する、まだ私はすべてのログが表示されませんも私は、ヘッダの値を見ています要求が入ってくる。

私は応答でなければならないと思うものについて、何かが実行されていないように見えるのか、予想されるアウトプットが間違っていることを理解していますか?私が紛失している可能性のある設定がありますか(トリガーの私の配布IDは、私たちが望むインスタンスに設定され、振る舞いは '*'に設定されています)?任意のヘルプは高く評価されています:)

+0

私は以下の主な問題に取り組んだと思いますが、ラムダ関数を更新して新しいトリガーをプッシュすると、あなたのサイトは数秒間保護されなくなります。トリガのアップデートは、少なくともラムダがそれらを制御することを許していない限り、アトミックではないようです...それは削除+追加です。 –

答えて

1

まず、いくつかのノート;

CloudFrontは(とりわけ)ウェブキャッシュです。

ウェブキャッシュの目的は、オリジンサーバーにリクエストを送信するのではなく、ブラウザに直接コンテンツを提供することです。

しかし、キャッシュが正しく行う必要がある最も重要なことの1つは、ではなく、が間違ったコンテンツを返します。キャッシュが間違ったコンテンツを返すことのできる方法の1つは、特定の要求ヘッダーが、指定されたURIに対して返される応答をoroginサーバーに変更させる可能性があることを認識していないことです。

CloudFrontにはこれを知る上での完璧な方法がないため、デフォルトでは、その解決策を元に戻す前に、ほとんどのヘッダーを要求から削除します。次に、受信したレスポンスをに対して正確ににキャッシュし、そのキャッシュレスポンスを将来のと同じリクエストにのみ使用します。

ビューア要求トリガーで新しいヘッダーを挿入すると、そのヘッダーが、一致するキャッシュ動作を通過した後に破棄されます。ただし、キャッシュ動作が特にそのヘッダーを転送元のヘッダーにホワイトリストするように構成されている場合を除きます。これは、ヘッダーがブラウザー自体によって注入された場合と同じ動作です。

したがって、このヘッダーを元に戻すソリューションは、キャッシュの動作設定でホワイトリストを作成することです。

ヘッダーがホワイトリストに登録されていないこの同じコードをOrigin Requestトリガーとして試した場合、CloudFrontは既にあなたがホワイトリストに登録されていないことを既に知っているヘッダーを挿入しようとしているので502 Bad Gatewayエラーをスローしますキャッシュの動作。 (ビューアリクエストでは、キャッシュビヘイビアの一致はまだ発生していないため、最終的には動作しないヘッダーを使用しているかどうかをCloudFrontが判断できません) Cache Behavior> Cache Check>(キャッシュミスの場合)Origin Request> Origin Serverに送信します。ヘッダーをホワイトリストに登録するとこれも解決されます。

ブラウザから来ているか、リクエストトリガーであるかにかかわらず、発信元に表示させるヘッダはすべてホワイトリストに登録する必要があります。

特に、CloudFrontを不正な目的(偽造やなりすましなど)で共同利用するために使用できるものと、単純に変更する意味がないものがあります。

+0

元気ですが、ログはどうですか?トリガーが実際にトリガーされた場合、CloudWatchログエントリは表示されませんか? – Jeff

+0

[アクセス許可が正しい場合](http://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html#lambda-edge-permissions)。ドキュメントは、私たちにログを書き込むと言うが、サービスが開始される直前に観察されたいくつかの変更に基づいて、必ずしも真実ではないかもしれない。トリガーが発火するエッジに最も近い領域にログインすることがあります。私はそれを確認する必要があります。 –

+0

現在、添付されている役割は、すべての標準ラムダで使用されている役割です。 CloudWatchのにログインするためのポリシーは次のとおりです。 { "バージョン": "2012年10月17日"、 "文":[ { "効果": "許可"、 "アクション":[ 「ログ: CreateLogGroup」、 "ログ:CreateLogStream"、 "ログ:PutLogEvents"、 "ログ:DescribeLogStreams" ]、 "リソース":[ "ARN:AWS:ログ:*:*:*" ] } ] } – Jeff

関連する問題