Skip to content

add audius_ddex_apps envvar#481

Merged
michellebrier merged 1 commit into
stagefrom
mbrier/proto-1683/metadata-uneditable
Feb 29, 2024
Merged

add audius_ddex_apps envvar#481
michellebrier merged 1 commit into
stagefrom
mbrier/proto-1683/metadata-uneditable

Conversation

@michellebrier

Copy link
Copy Markdown
Contributor

Description

@gitguardian

gitguardian Bot commented Feb 28, 2024

Copy link
Copy Markdown

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request
GitGuardian id GitGuardian status Secret Commit Filename
2416686 Triggered Generic High Entropy Secret 7206770 discovery-provider/stage.env View secret
2460751 Triggered Generic High Entropy Secret 7206770 discovery-provider/prod.env View secret
🛠 Guidelines to remediate hardcoded secrets
  1. Understand the implications of revoking this secret by investigating where it is used in your code.
  2. Replace and store your secrets safely. Learn here the best practices.
  3. Revoke and rotate these secrets.
  4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider


🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!

@theoilie theoilie left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rather than add an env var to every discovery node, why don't we use existing db data?

  • to verify an app's existence: select * from "developer_apps" where address = '0x<ddex_key>'
  • to verify userId has delegated write permission to an app: select * from "grants" where user_id = '<decoded_id>' and grantee_address = '0x<ddex_key>' and is_revoked=f and is_current=t and is_approved=t

@theoilie theoilie left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe i misunderstood. this env var list is just to differentiate between a ddex app and a non-ddex app? that makes sense so maybe we leave it for now, but long-term it would mean any third party running a DDEX app would need to make a code change.

the first alternative that comes to mind is making the app creation UI have a checkbox for "is DDEX" which corresponds to a column in the developer_apps table for us to reference when indexing cc @nicoback2

edit: i should've read the other PR first. looks like you're already thinking of doing this here, nice!

@michellebrier

Copy link
Copy Markdown
Contributor Author

maybe i misunderstood. this env var list is just to differentiate between a ddex app and a non-ddex app? that makes sense so maybe we leave it for now, but long-term it would mean any third party running a DDEX app would need to make a code change.

the first alternative that comes to mind is making the app creation UI have a checkbox for "is DDEX" which corresponds to a column in the developer_apps table for us to reference when indexing cc @nicoback2

edit: i should've read the other PR first. looks like you're already thinking of doing this here, nice!

yeah my bad for no context - explanation in the other PR
didn't want to just query to the existing developer apps tables while they don't have any DDEX context as I think that would allow any app to edit DDEX tracks

@michellebrier michellebrier merged commit 154f0d4 into stage Feb 29, 2024
@michellebrier michellebrier deleted the mbrier/proto-1683/metadata-uneditable branch February 29, 2024 06:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants