Sentry-react-native: Invalid DSN, the following properties aren't set '[secret key]'

[antoinerousseau]

OS:

• [ ] Windows
• [x] MacOS
• [ ] Linux

_Platform:_

• [ ] iOS
• [x] Android

Output of node -v && yarn version

v6.10.2
yarn version v0.27.5

Config:

Sentry.config('https://[email protected]/...').install()

---

I have following issue:

I followed the auto install steps, the java files seem properly modified, but the app crashes.

Steps to reproduce:

• `yarn add react-native-sentry``
• react-native link react-native-sentry & answer questions
• My sentry.properties is properly generated:

defaults.url=https://sentry.io/
defaults.org=tribeez
defaults.project=wedofamilies
auth.token=8bfxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx219
cli.executable=node_modules/sentry-cli-binary/bin/sentry-cli

Actual result:

Expected result:

• Working app

[antoinerousseau]

OK found the cause, I was using a public DSN instead of the one including the secret key.
The error was quite clear in the end, thanks!
I was migrating from raven-js which was using the public DSN.

[HazAT]

Hey, thanks for pointing this out. We will in some point in the future remove the secret part of the DSN so this should no longer happen.

[miracle2k]

I was searching for this, because I had this exact question. Isn't it a bad thing to ship the secret key with the app? I'd essentially be exposing it publicly. Or is it not a big deal?

[HazAT]

It's not a big deal, the security implication is only that someone can send events on your behalf, which your only resolve is to revoke the API key and ship a new one. There's no other access given by default with client keys.
This is mostly the same for all analytics/error tracking apps out there.

[miracle2k]

Thanks. I found this discussion with more information about the difference: https://github.com/getsentry/sentry/issues/3696

[leethree]

I don't think it's a good idea to ship secrets within the app. Client apps should be treated the same as browsers. If the secrets don't make a difference, Sentry SDK should allow using Public DSN instead of DSN with secrets.

[HazAT]

@leethree You are right and we are currently working on this.
Technically it‘s no secret, we will drop the „secret“ part in the future but nothing to announce yet.
For now please use the DSN with a secret.

[leethree]

@HazAT Glad to hear! Thanks a lot!

[BaptisteT]

Hello @HazAT, is there any plan to drop the secret part soon?

[HazAT]

@BaptisteT inofficially it has been merged today and will soon hit prod, but psst 🤐
https://github.com/getsentry/sentry/pull/6786

[vladikoff]

@HazAT when would that be available in the open source release? I don't see any releases this year at https://github.com/getsentry/sentry/releases

[HazAT]

@vladikoff We are currently in the process of releasing a major update (Sentry 9).
Sorry, for the inconvenience please stay tuned.

[vladikoff]

No worries, just checking!

On Mon, Apr 16, 2018, 03:17 Daniel Griesser [e-mail]
wrote:

@vladikoff https://github.com/vladikoff We are currently in the process
of releasing a major update (Sentry 9).
Sorry, for the inconvenience please stay tuned.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/react-native-sentry/issues/224#issuecomment-381502652,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH289MA11LNwTPQY5PIIPN9oCt1LrLlks5tpEWUgaJpZM4PO7AM
.

[jamesisaac]

Got caught out by this as the docs suggest using the new style DSN, but that still doesn't seem supported in 0.38.1 (latest).

And the error message doesn't really bubble up, so you just see a cryptic Error during init / createErrorFromErrorData (I suspect this was the issue for #432).

[HazAT]

@jamesisaac I just tried it with a clean example and it works just fine with the "public" DSN.

[jamesisaac]

Hmm, anything I can do to help you debug? RN 0.55.3 project. I first installed/linked Sentry a couple of days ago, yarn.lock:

react-native-sentry@^0.38.1:
  version "0.38.1"
  resolved "https://registry.yarnpkg.com/react-native-sentry/-/react-native-sentry-0.38.1.tgz#a65540db41886cc0dd803012b0044b8e9f38199a"

After adding e.getMessage() to the promise.reject call I saw the error was:

07-09 11:29:56.282 22024 22082 W ReactNativeJS: Possible Unhandled Promise Rejection (id: 0):
07-09 11:29:56.282 22024 22082 W ReactNativeJS: Error: Error during init Invalid DSN, the following properties aren't set '[secret key]'
07-09 11:29:56.282 22024 22082 W ReactNativeJS: createErrorFromErrorData@http://localhost:8081/index.delta?platform=android&dev=true&minify=false:2039:26

Switching back to legacy DSN did indeed solve the error.

[jamesisaac]

One more note is that this only happened when running in dev (OS: Windows / Platform: Android). Integration seemed to work fine and correctly send errors in release builds with the public DSN.

[HazAT]

@jamesisaac version 0.38.2 is on its way fixing this issue.

[jamesisaac]

Great! Thanks.