标签: aws-lambda-edge

我看到人们在谈论如何根据各种信息重写 URI。但我想规范化请求的域名。这是我尝试过的：

exports.handler = (event, context, callback) => {
    const request = event.Records[0].cf.request;

    if (request.method.toUpperCase() != 'GET') {
        callback(null, request);
        return;
    }

    request.origin = {
        custom: {
            domainName: 'slashdot.org',
            port: 443,
            protocol: 'https',
            path: request.uri
        }
    };
    request.headers.host = {
        "key": "Host",
        "value": request.origin.custom.domainName
    };

    console.log("returning req:", request);

    callback(null, request);
}

我希望这会拉起请求，然后 Cloudfront 会针对我的规范化域发出请求。（对于示例和测试，我使用的是 slashdot，因为很明显它不是我的内容）。

最终，我试图规范化请求而不进行重定向，而是在命中命中源之前重写请求。

我的目标是保护 aws s3 存储桶链接，我试图通过使用 cloudfront 作为可访问 s3 存储桶的链接来解决这个问题，因此，当用户尝试访问 cloudfront 链接时，如果有的话，就会有一个基本的身份验证他们的浏览器中没有 cookie，但如果有 cookie，则会检查该 cookie 中的身份验证值并授予用户访问权限。PS：这不是一个网站，我的任务是保护 s3 存储桶链接。

这是我的尝试，使用 lambda@edge，根据查看者的请求，如果用户未登录，则有身份验证页面，否则，他们被允许访问，它可以工作，但我无法设置 cookie，因为在 aws 文档、cloudfront 中的某处删除标头文件中的 set-cookie：CloudFront 从转发到您的源的请求中删除 Cookie 标头，并从返回给您的查看者的响应中删除 Set-Cookie 标头

这是我的代码：

'use strict';

// returns a response error
const responseError = {
                status: '401',
                statusDescription: 'Unauthorized',
                headers: {
                    'www-authenticate': [{key: 'WWW-Authenticate', value:'Basic'}]
                }
};




exports.handler = (event, context, callback) => {
    // Get request and request headers
    console.log(event.Records[0]);
    const request = event.Records[0].cf.request;
    const response = event.Records[0].cf.response;
    const headers = request.headers;



    // …

我想从 Lambda@Edge 卸载一些功能以加快响应时间。这意味着在我的 Lambda@Edge 中触发另一个 Lambda 函数。

Lambda@Edge 将应用程序分布在所有区域，因此当发出请求时，它将在距离请求者最近的区域执行应用程序。

我当前的解决方案是在所有区域创建一个具有相同主题名称的 SNS，让 us-east-1 中的 SQS 监听所有这些 SNS 主题，并使用 Lambda 函数监听 SQS。

然而，在每个地区创建一个SNS 维护起来相当麻烦。

关于如何在 Lambda@Edge 中触发另一个 Lambda 函数，还有其他建议吗？

谢谢！

需要您的帮助来理解一些概念。我有一个在 CloudFront 上使用 Lambda@Edge 的 Web 应用程序。此 lambda 函数访问 DynamoDB - 进行大约 10 个独立查询。这偶尔会产生错误，尽管当我单独测试 lambda 函数时它工作得很好。我无法从 Cloudfront 日志中获得太多意义，并且 Lambda@Edge 没有显示在 CloudWatch 中。

我感觉 DynamoDB 查询是罪魁祸首。（因为这就是我在 Lambda 函数中所做的全部事情）为了确保这一点，我在所有区域复制了数据。但这并没有解决问题。我增加了分配给 lambda 函数的超时和内存。但这没有任何帮助。但是，减少数据库查询的数量似乎有所帮助。

你能帮我理解这一点吗？在 Lambda@Edge 中进行数据库查询是否错误？有没有办法获取 Lambda@Edge 的详细日志？

如果我的理解正确的话，从堆栈中提供 APILambda@Edge比从堆栈中提供 API 提供更多的延迟优势API-Gateway + Lambda。

另外，API-Gateway 的成本（3.5 美元/百万次调用）+ Lambda（0.2 美元/百万次调用）== 3.7 美元/百万次调用似乎比Lambda@Edge（0.6 美元/百万次调用）更昂贵。

如果上述两个观察结果都是正确的，那么我们不应该将我们的 API-Gateway + Lambda （对于那些使用此堆栈的人）迁移到 lambda@edge 堆栈吗？

我正在尝试对 HTTP 301 重定向执行如下操作，以便网络用户将重定向到不同的新闻页面。

    if ((request.uri == "/news") || (request.uri == "/news/") && (request.origin.domainName == "sub.mydomain.com")) {

        
        const redirectResponse = {
            status: '301',
            statusDescription: 'Moved Permanently',
            headers: {
                'location': [{
                    key: 'Location',
                    value: '/local-news/',
                }],
                'cache-control': [{
                    key: 'Cache-Control',
                    value: "max-age=3600"
                }],
            },
        };
        callback(null, redirectResponse);
   
  }

但是，似乎这个request.origin.domainName == "mydomain.com"部分在我的函数中不起作用。这是选择客户端来自的域名的正确方法吗？

我认为此request.origin.domainName方法将无法作为仅适用于Origin 请求的Origin对象支持。我是否有可能获得查看者请求的客户端的域名？