Separating sentry interface and relay via different domains

[ermyril]

Hello!
I’ve got my sentry up and running on sentry.example.com, but now it’s necessary to separate sentry admin panel and the endpoint for reports, which is in my case could be done only via separate domains. So what I want to get is something like that

upstream sentry {
        server 127.0.0.1:9000;
}
server {
            listen 443 ssl http2;
            server_name sentry.example.com;
            ...
            location / {
                deny  all;
            }
            location ~ ^/api/[1-9]\d*/ {
                    proxy_pass http://sentry;
            }
}
server {
            listen 443 ssl http2;
            server_name sentryadmin.example.com;
            ...
            location / {
                    proxy_pass http://sentry;
            }
}

which should, as I thought, separate requests for sentry and relay on the level of my nginx (standalone), and pass them into the nginx in the container

But I’m not able to do it, requests from sentryadmin.example.com are being passed through to the sentry, but it goes into the redirect-loop, while sentry.example.com works fine.

What am I missing here? Is it a viable solution? Is it possible to do so?
Now I’m thinking about spinning up the nginx container which will replace the default onpremise nginx and doing the proxying from there.

I’ve seen suggestions to use sentry relay for something similar, but there is already a default relay container so It would be ideal to use it instead of creating another one.

[BYK]

@ermyril

But I’m not able to do it, requests from sentryadmin.example.com are being passed through to the sentry, but it goes into the redirect-loop, while sentry.example.com works fine.

I think all you need to do is Host header rewriting so Sentry still thinks it is getting requests for sentry.example.com. You may also need to check some cookie settings to make sure they make it through. I’m assuming the redirect loop is caused by the host discrepancy and lack of session cookie persistence.

Regarding whether this is viable or not: I personally wouldn’t do it as it seems to be a maintenance burden. That said I don’t think I fully understand the problem you are set to solve. Can you provide more details so we may be able to work out a simpler/easier solution?

[ermyril]

Thanks!
I tried setting Host header, but it didn’t work, I’ll try it again a little later in case if I missed something.

About my case: We’re setting up sentry in a client’s infrastructure, after initial setup we’re decided that it will be better to deny access to the admin-panel of sentry for all IP addresses except for whitelisted ones. While the /api/[1-9]/ endpoints should be accessible from the internet because we’re using sentry for error-monitoring mobile apps and javascript applications.

Firstly I tried to just use nginx ngx_http_access_module for it, but it appears that because of the client’s routing configuration all requests to the sentry machine are coming from a single ip address and without x-forwarded-for headers.
I’ve asked if the guys can setup ip whitelisting for a specific routes on their routers, but they said that ip whitelisting is possible only for whole domains and not for the specific routes. So my thought is to use two different domains - one for the access of the sentry interface itself and the other one which will be used for collection of the error reports.