Expo React Native密钥与URL安全存储及EAS命令问题咨询

1. Best Practices for Public API URL Storage #

• Use the EXPO_PUBLIC_ prefix in .env files: This is Expo's official method for exposing non-sensitive environment variables to your app code. Centralizing URLs here lets you update them without editing multiple files across your project.
• Never put sensitive data in EXPO_PUBLIC_ variables: Any variable with this prefix gets bundled directly into your app's JavaScript bundle, so it’s visible to anyone who inspects the app files.
• Commit a .env.example but ignore .env: Add .env to your .gitignore to prevent accidental commits of environment values, and provide a .env.example with placeholder entries for other developers to reference.

2. Secure Management of Sensitive Keys #

• Do not store sensitive keys in .env: Even without the EXPO_PUBLIC_ prefix, .env files are at risk of accidental exposure via version control or shared project files.
• Leverage EAS Secrets:
  • Use eas secret:create to add secrets tied to your project or Expo account. These are stored securely on Expo’s servers and injected into your build environment at compile time—never exposed in the final app bundle.
  • Choose the appropriate scope: Use project scope for app-specific secrets, and account scope for secrets shared across multiple projects in your organization.
  • Access build-time secrets in configuration: Reference secrets in app.config.js or app.json using process.env.SECRET_NAME for build-time configuration (e.g., setting up third-party services).
• Runtime secrets: Use a backend proxy: If you need to use a secret during app runtime (e.g., for an API call that requires authentication), never embed it in the app. Instead, create a backend endpoint that handles the API request using the secret, then have your app call this backend. This keeps sensitive keys isolated on your server.

3. Interpreting eas secret:list Output #

• Both your key-value format and the expected table format are valid—output style depends on your EAS CLI version. Older CLI versions display individual secrets in a vertical layout, while newer versions use a table when multiple secrets exist.
• Critical details to verify:
  • Name: Matches the identifier you used when creating the secret (e.g., CONSUMER_KEY).
  • Scope: Confirms whether the secret is tied to your project or account.
  • Type: STRING for text-based secrets, FILE for file-based secrets (e.g., keystores).
  • Updated at: Shows the last time the secret was modified.
• To get the table format, update your EAS CLI to the latest version with npm install -g eas-cli.
• For a clear, machine-readable list of all secrets, run eas secret:list --json.

Critical Fix for Your Current Setup #

Remove CONSUMER_KEY and CONSUMER_SECRET from your .env file immediately—these are sensitive values that should be stored as EAS Secrets instead. Ensure .env is in your .gitignore to avoid exposing any remaining values.

内容的提问来源于stack exchange，提问作者JISHNU T RAJ