Implementierung der Lambda @ Edge-Authentifizierung für CloudFront

Question

Ich möchte den Lambda @ Edge zu einem unserer Dienste hinzufügen. Das Ziel besteht darin, die URL für bestimmte Werte neu festzulegen und diese mit einem Headerwert zu vergleichen, um die Autorisierung sicherzustellen. Wenn der Wert vorhanden ist, wird er verglichen, und wenn er zurückgewiesen wird, sollte 403 sofort an den Benutzer zurückgegeben werden. Wenn der verglichene Wert übereinstimmt oder die URL keinen bestimmten Wert enthält, wird die Anfrage als autorisierte Anfrage fortgesetzt.

Anfangs dachte ich, dass dies mit einem "Viewer Request" Ereignis auftreten würde. Einige der Posts und Kommentare zu SO deuten darauf hin, dass die "Ursprungsanfrage" für diese Überprüfung ideal ist. Aber im Moment habe ich versucht, mit den Beispielen in der Dokumentation zu einem unserer CF-Endpunkte herumzuspielen, aber ich sehe keine erwarteten Ergebnisse. Der Code ist die folgende:

'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); 
}; 

Ich würde erwarten, dass es ein angemeldeter Wert innerhalb Cloudwatch sein sollte und ein neuer Header Wert in der Anforderung, aber ich sehe keine Protokolle noch bin ich den Header-Wert sehen, wenn die Anfrage kommt rein.

Kann jemand etwas Licht in die Frage bringen, warum die Dinge scheinbar nicht ausgeführt werden, was meiner Meinung nach die Antwort sein sollte? Ist mein Verständnis davon, was die erwartete Ausgabe falsch ist? Gibt es eine Konfiguration, die ich vermisse (Meine Verteilungs-ID im Auslöser ist auf die gewünschte Instanz eingestellt und das Verhalten wurde auf '*' gesetzt)? Jede Hilfe wird geschätzt :)

Answer 1

Zuerst ein paar Notizen;

CloudFront ist (unter anderem) ein Web-Cache.

Ein Web-Cache dient dazu, Inhalte direkt an den Browser zu senden, anstatt die Anfrage an den Ursprungsserver zu senden.

Eines der kritischsten Dinge, die ein Cache richtig machen muss, ist nicht geben Sie den falschen Inhalt zurück. Eine Möglichkeit, wie ein Cache den falschen Inhalt zurückgeben kann, besteht darin, dass nicht erkannt wird, dass bestimmte Anforderungsheader den orogin-Server veranlassen können, die Antwort zu ändern, die er für einen bestimmten URI zurückgibt.

CloudFront hat keine perfekte Möglichkeit, dies zu wissen, deshalb ist seine Lösung - standardmäßig - fast alle Header aus der Anfrage zu entfernen, bevor sie an den Ursprung weitergeleitet werden. Dann speichert es die empfangene Antwort gegen genau die Anforderung, die es an den Ursprung gesendet hat, und verwendet nur diese zwischengespeicherte Antwort für zukünftige identische Anforderungen. Wenn ein neuer Header in einem Viewer Request-Trigger eingefügt wird, wird dieser Header verworfen, nachdem er das entsprechende Cache-Verhalten durchlaufen hat, es sei denn, das Cache-Verhalten ist speziell so konfiguriert, dass dieser Header für die Weiterleitung an den Ursprung auf die weiße Liste gesetzt wird. Dies ist das gleiche Verhalten, das Sie sehen würden, wenn der Header selbst vom Browser injiziert wurde.

Ihre Lösung, um diesen Header zum Ursprung durchzuleiten, besteht also darin, ihn in den Cache-Verhaltenseinstellungen aufzulisten. Wenn Sie denselben Code wie einen Origin Request-Trigger ausprobiert haben, ohne den Header auf die weiße Liste gesetzt zu haben, würde CloudFront tatsächlich einen 502 Bad Gateway Fehler werfen, weil Sie versuchen, einen Header zu injizieren, von dem CloudFront bereits weiß, dass Sie ihn nicht in die Trefferliste aufgenommen haben Cacheverhalten. (In Viewer-Anforderung ist die Übereinstimmung des Cache-Verhaltens noch nicht eingetreten, daher kann CloudFront nicht feststellen, ob Sie etwas mit den Headern tun, die letztendlich nicht funktionieren. In Origin Request ist dies bekannt.) Der Ablauf ist Viewer-Anforderung> Cache-Verhalten> Cache-Prüfung> (wenn Cache-Verfehlung) Origin Request> an Origin Server senden. Whitelisting der Header würde dies auch auflösen.

Jede Kopfzeile, die der Ursprung sehen soll, ob sie vom Browser oder einem Anforderungsauslöser kommt, muss auf die weiße Liste gesetzt werden.

Beachten Sie, dass some headers are inaccessible or immutable, insbesondere solche, die verwendet werden könnten, um CloudFront für betrügerische Zwecke (wie Anfrage Fälschung und Spoofing) kooptieren und diejenigen, die einfach keinen Sinn zu ändern.