Sentry-python: sdk do NOT support dsn with subpath

[vincenthcui]

By some reason, we can't use a absolute domain for sentry, so we use subpath instead like company.io/sentry/project_id. But sentry-python think project_id as int, and think the dsn above is invalid.

Exception:

sentry_sdk.utils.BadDsn: Invalid project in DSN (u'sentry/848')

[untitaker]

Which version of sentry (server) are you using? I am told that we just don't support subpath installations anymore since at least 2017: https://github.com/getsentry/sentry/pull/5174

[untitaker]

We're going to backport this anyway due to proxies running in front of sentry.

[vincenthcui]

@untitaker Version 9.0.0

[untitaker]

Will be fixed in the next release. Thanks for your patience!

[mitsuhiko]

Reopening because we need to revisit this. Not supporting subpaths was an intentional change and is already not supported in a lot of environments.

[mitsuhiko]

@vincenthcui how do you have sentry deployed that sentry is at a non root path? That should not work.

[untitaker]

As discussed this is at least useful when you have a reverse proxy
specifically for store. I don't see the harm in having it

On Thu, Jan 3, 2019, 00:22 Armin Ronacher <[email protected] wrote:

@vincenthcui https://github.com/vincenthcui how do you have sentry
deployed that sentry is at a non root path? That should not work.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry-python/issues/212#issuecomment-451016228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzHxa0ybYd60DI7Ws-uAfl80bHYegEUks5u_T9JgaJpZM4ZV7oq
.

[mitsuhiko]

@untitaker If we want to bring it back we need to do it properly. This is not documented behavior and it's not supported by relay or any other new SDK.

[mitsuhiko]

This is the current spec on how a DSN is supposed to be parsed: https://docs.sentry.io/development/sdk-dev/overview/#parsing-the-dsn

[wedamija]

This change breaks Sentry's usage of Auth and is causing a subset of tests to fail. I'll pin to an older version for now, but if you need to introduce a new value into Auth's constructor could you make it optional?

(See https://github.com/getsentry/sentry/blob/da920dda23598ef3137b2b829cbce48570daa99c/src/sentry/utils/sdk.py#L136 for usage)

[untitaker]

Alright let's just revert this then

On Thu, Jan 3, 2019, 02:12 Dan Fuller <[email protected] wrote:

This change breaks Sentry's usage of Auth and is causing a subset of
tests to fail. I'll pin to an older version for now, but if you need to
introduce a new value into Auth's constructor could you make it optional?

(See
https://github.com/getsentry/sentry/blob/da920dda23598ef3137b2b829cbce48570daa99c/src/sentry/utils/sdk.py#L136
for usage)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/getsentry/sentry-python/issues/212#issuecomment-451033207,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAzHxcAfeuPmQeFt2D-jOxNMH7l2yv33ks5u_VjlgaJpZM4ZV7oq
.

[untitaker]

I reverted this in master at https://github.com/getsentry/sentry-python/commit/d44a02f054372aaad5555cd2e6997f9e47fb7cb0

I am fine with not supporting subpaths at all.

[wedamija]

Thanks @untitaker, could you ping me on the next pypi release? I'll unpin the sdk version once it's out

[untitaker]

@wedamija 0.6.6 is released