Cannot change SENTY_PUBLIC to true after Docker based installation

Hello Team,

I have installed Sentry On-Premise (Docker-based installation) on our on-premise Linux servers (behind a firewall). I have set the reverse proxy URL(from Azure AD) as the ROOT URL. Hence users are able to register and access SENTRY from the URL.

But the issue is that the events from the client side are not flowing to Sentry, although the SDK has been installed on the client-side and necessary configuration is made.

But looking closely, As per the documentation, since Sentry is Behind a firewall, we would need to set
SENTRY_PUBLIC = True
But unfortunately, I was unable to do so.
I tried to set it in sentry.conf.py file and executed docker-compose build and docker-compose up -d, but it did not replicate the changes.

Kindly advise me if I am trying to do something wrong over here.
Does SENTRY_PUBLIC = True need to be set in my case?

Please let me know if any further information is needed.
Thanks in Advance.

Best Regards
Naveen

I don’t think this setting applies to you, the docs are a bit misleading there (lack of context around this setting). I’d check my SDK configuration and the DSNs set in them.

Hello BYK,

Thank you very much for your reply. But now After my below step

I tried to set it in sentry.conf.py file and executed docker-compose build and docker-compose up -d , but it did not replicate the changes.

Sentry stopped working for me. How do I bring it back up?

You very likely have a typo or an error in your configuration. You can run docker-compose logs -f web to see why they are failing.

django.core.exceptions.ImproperlyConfigured: You must configure ``cache.backend``.
This is the error I seem to be facing.
How do I resolve this error? Any suggestions?
I removed the sentry.conf.py file and executed docker-compose build and docker-compose up -d
Still no use.
Kindly advice.

Are you 100% sure the following keys in your config file are properly configured:

-CACHES

  • SENTRY_CACHE

I’d run docker-compose down && docker-compose build web && docker compose up -d to make sure everything gets propagated properly.

It works. Thanks.
The issue was that I had made some modifications in the sentry.conf.py file which has led to this issue.

1 Like

Coming back to the original issue.
We have followed the instructions based on ‘https://docs.sentry.io/platforms/react-native/
The DSN is configured on our index.tsx file. which looks something like:

Sentry.init({

dsn: 'https://<app-secret>@sentry-organization.msappproxy.net/4',

environment: 'dev',

debug: true,

maxBreadcrumbs: 50,

})

We did try to run the app for testing and it seems like it somehow faces an issue with our token in Azure AD proxy.

Below are the logs:

DEBUG 2020-03-18 19:52:31.856913 +02:00 request GET https://sentry-organization.msappproxy.net/api/0/organizations/organization/chunk-upload/
DEBUG 2020-03-18 19:52:31.858065 +02:00 using token authentication
DEBUG 2020-03-18 19:52:31.858527 +02:00 retry number 0, max retries: 0
DEBUG 2020-03-18 19:52:32.154274 +02:00 > GET /api/0/organization/o/chunk-upload/ HTTP/1.1
DEBUG 2020-03-18 19:52:32.154697 +02:00 > Host: sentry-organization.msappproxy.net
DEBUG 2020-03-18 19:52:32.154994 +02:00 > Accept: /
DEBUG 2020-03-18 19:52:32.155280 +02:00 > Connection: TE
DEBUG 2020-03-18 19:52:32.155552 +02:00 > TE: gzip
DEBUG 2020-03-18 19:52:32.155815 +02:00 > User-Agent: sentry-cli/1.51.1
DEBUG 2020-03-18 19:52:32.156914 +02:00 > Authorization: Bearer d983b7e0***
DEBUG 2020-03-18 19:52:46.659285 +02:00 < HTTP/1.1 302 Found
DEBUG 2020-03-18 19:52:46.660034 +02:00 < Content-Length: 0
DEBUG 2020-03-18 19:52:46.660903 +02:00 < Location: ***
DEBUG 2020-03-18 19:52:46.661310 +02:00 < Server: Microsoft-HTTPAPI/2.0
DEBUG 2020-03-18 19:52:46.661581 +02:00 < Set-Cookie: AzureAppProxyAnalyticCookie_***
DEBUG 2020-03-18 19:52:46.661928 +02:00 < Date: Wed, 18 Mar 2020 17:52:45 GMT
DEBUG 2020-03-18 19:52:46.662670 +02:00 response status: 302
DEBUG 2020-03-18 19:52:46.663166 +02:00 body:
error: not a JSON response

This looks suspicious, why is it issuing a 302 redirect? I think Azure AD proxy is requiring auth then not accepting the bearer token for some reason and issuing a redirect to the interactive login page.

You are absolutely correct. We found out that the Bearer token being used here is the ‘Auth-Token’ which we created from Sentry, rather than the Access Token which was provided by the Azure AD. We are working to resolve this issue.

I would appreciate if you can provide links to any documentation (if available) that mentions about seamlessly integrating Azure AD with Sentry.

1 Like

So yes, OnPremise is installed on a server that requires Azure AD to be accessible. Nor me, nor my colleagues could not find any relevant documentation about providing additional auth headers(especially for our stack, which would be OnPremise on the company server/PC and React Native apps).

Looking through the code we figured that we can not add any additional headers for iOS or Android:
https://github.com/getsentry/sentry-cocoa/blob/3c7ff35cc03bd05ce9d50a87b5c3162a5460a8b5/Sources/Sentry/SentryClient.m#L262

So I am correct to assume we need to open the self-hosted sentry for it to work(by removing Azure AD auth requirement)?
Also, this would mean that we would need to extend sentry functionality for our needs for our stack to allow the usage of Azure AD?

The nodejs version of Sentry seems to have possibility (not tested, just browsing the source code) be adjusted to add headers through the transportOptions.headers.

To add here the iOS version of the native code.

I could not find from iOS or Android native code a way to add custom headers, so it would require changes for both of those and the RN native module to pass such information.

The sentry-cli implementation I didn’t check how it makes the requests to the api path. But obviously would require parameters for cli for custom headers, but then again getting token for the AD will be a bit problematic for server side as it would be DevOps Pipelines running the command. Would need to be some persisting token.

@ddzirt @jounii your two issues seem entirely unrelated to this thread. Please create a new one.

We don’t have such a thing unfortunately, sorry :frowning: