Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to decrypt universal import payload #29

Closed
jdjkelly opened this issue Jan 17, 2023 · 2 comments
Closed

Unable to decrypt universal import payload #29

jdjkelly opened this issue Jan 17, 2023 · 2 comments

Comments

@jdjkelly
Copy link

We're using @dopplerhq/universal-import-core to build an integration with an internal admin tool to push secrets over to Doppler.

Locally, the connection works fine - trigger successfully renders the Doppler import screen.

In production, the connection renders "Unable to decrypt universal import payload". An example request ID for debugging purposes: 48aed283-6bd5-4956-ac3e-5de84d6a03b8

In both cases, we can see a fetch request being made to https://keys.doppler.com/universal-import/latest.json?cpv=1.0.0 which, in both cases, returns:

{
    "keyId": "dea124b0-a69f-464a-870b-317f9ccaf65b",
    "publicKey": "4x+ohnrLt42vE3lIq2y6Nozs/KI9lAYkREhb56grxhg="
}

Any ideas?

@Kunamatata
Copy link
Contributor

Thanks for reaching out @jdjkelly. For security reasons we are unable to see the payload you are attempting to trigger the import with, namely the secret name and secret value.
One common issue we have identified is that the secret name might not be matching Doppler's secret naming convention.

Would you mind sharing the shape of the secret name you are providing?

Doppler's secret naming convention is as follows:

Secret names must adhere to a specific format:

  • Secret names may only contain uppercase letters, numbers, and underscores
  • Secret names may not start with a number

We will be updating both universal-import-core and unviersal-import-react packages to contain this validation and log an error to the console.

@jdjkelly
Copy link
Author

This was resolved over email with Max.

Root cause is undetermined, but proximate cause was being on NextJS <= 13.0.4 (we were on 13.03 and upgrading to 13.0.5 has resolved). Strongly suspect somewhere in the transpiration of ESM to CommonJS in Next builds is the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants