【问题标题】:How to avoid hardcoding AWS Cognito data in the app如何避免在应用程序中硬编码 AWS Cognito 数据
【发布时间】:2020-06-17 19:34:32
【问题描述】:

我正在创建一个连接到 AWS 服务的 Electron 应用程序。在可以访问服务之前,用户需要使用 AWS Cognito 进行身份验证。为了让用户进行身份验证,我需要在客户端应用程序中硬编码应用程序区域、用户池 ID、身份池 ID 和应用程序客户端 ID。硬编码这是一个糟糕的主意,因为这些值会因客户端而异。

在我的应用程序中,用户从不直接与数据库交互,否则我会让他们查询数据库以获取这些数据。用户连接到 Elastic Beanstalk 端点,我的 EC2 实例是唯一允许与数据库通信的实例。这提高了安全性。

避免对此类数据进行硬编码的最佳方法是什么?

【问题讨论】:

  • 在您的 EB 应用程序上公开一个 API 路由,客户可以从中请求 Cognito 信息?

标签: amazon-web-services amazon-cognito software-design


【解决方案1】:

一般来说,配置应该存储在环境中(参见https://12factor.net/)。

这对于不同的环境意味着什么不同,我对电子一无所知,但是您的配置值将在构建时知道,因此当您构建客户端时,您可以构建一个 environment.js 文件,其值可以是从您的应用中引用。

使用 CloudFormation 和 CodePipeline 的示例

所以,也许您正在使用 CloudFormation 来配置您的 Cognito 基础架构。在这种情况下,您可以export variables 可以被其他 CloudFormation 模板引用。

这些导出的应用程序客户端 ID、用户池 ID、身份池 ID 等可以注入到 CloudFormation 模板中,该模板定义了一个 CodePipeline 实例,您可以使用该实例来构建您的电子应用程序,以下可能是其中的一个片段:

...
BuildElectronProject:
    Type: AWS::CodeBuild::Project
    Properties:
      Name: electron-build
      Artifacts:
        Type: CODEPIPELINE
      Environment:
        ComputeType: BUILD_GENERAL1_SMALL
        EnvironmentVariables:
          -
            Name: AWS_REGION
            Value: !Ref 'AWS::Region'
          -
            Name: USER_POOL_ID
            Value: !ImportValue 'user-pool-id'
          -
            Name: SERVER_URL
            Value: !Join
              - ''
              -
                - !If [ IsProd, 'https://', 'http://' ]
                - !FindInMap [ Environments, !Ref Environment, ServerUrl ]
...

然后,当您构建应用程序时,您可以使用 CodeBuild 中的环境变量来创建 environment.js 文件,该文件包含在您的可分发电子构建中。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2019-07-06
    • 1970-01-01
    • 2022-10-31
    • 2016-05-11
    • 1970-01-01
    • 2011-02-10
    • 2013-09-09
    相关资源
    最近更新 更多