getsentry / getsentry/self-hosted
CPU/RAM Usage beacon broadcast system - Requires superuser - Google Auth
- Dominant language
- Shell
- Stars
- 9.6k
- Forks
- 2k
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 12
Description
Yesterday I upgraded our Sentry in our test environment. 23.9.1 -> 23.11.0. Started everything, logged in, everything was fine. Then I upgraded to 24.8.0.
After install and I started everything. Navigated to the web ui and was asked:
```
We have made some updates to our self-hosted beacon broadcast system, and just need to get a quick answer from you.
CPU/RAM Usage
Recording CPU/RAM usage will greatly help our development team understand how self-hosted sentry is typically being used, and to keep track of improvements that we hope to bring you in the future.
Yes, I would love to help Sentry developers improve the experience of self-hosted by sending CPU/RAM usage
No, I'd prefer to keep CPU/RAM usage private
```

On Continue Im getting this dialog
"You are attempting to access a resource that requires superuser access, please re-authenticate as a superuser."

We are using Google Auth (https://develop.sentry.dev/self-hosted/sso/#google-auth)

Not really an option to sign in with another user.
My user is "Owner". If another user signs in (manager) he wont get this question
If no password is inserted Im getting this

If a password is provided, Im getting this

sentry-self-hosted-web-1 log:
```
06:46:30 [WARNING] django.request: Forbidden: /api/0/internal/options/ (status_code=403 request=)
06:46:30 [INFO] sentry.access.api: api.access (method='GET' view='sentry.api.endpoints.authenticator_index.AuthenticatorIndexEndpoint' response=200 user_id='1' is_app='False' token_type='None' is_frontend_request='True' organization_id='None' auth_id='None' path='/api/0/authenticators/' caller_ip='192.1.1.2' user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' rate_limited='False' rate_limit_category='None' request_duration_seconds=0.01604628562927246 rate_limit_type='DNE' concurrent_limit='None' concurrent_requests='None' reset_time='None' group='None' limit='None' remaining='None')
06:46:31 [INFO] sentry.api.endpoints.auth_index: auth-index.validate_superuser (user=1 raise_exception=True verify_authenticator=False)
06:46:31 [INFO] sentry.access.api: api.access (method='PUT' view='sentry.api.endpoints.auth_index.AuthIndexEndpoint' response=400 user_id='1' is_app='False' token_type='None' is_frontend_request='True' organization_id='None' auth_id='None' path='/api/0/auth/' caller_ip='192.1.1.2' user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' rate_limited='False' rate_limit_category='None' request_duration_seconds=0.019124984741210938 rate_limit_type='DNE' concurrent_limit='None' concurrent_requests='None' reset_time='None' group='None' limit='None' remaining='None')
06:46:31 [WARNING] django.request: Bad Request: /api/0/auth/ (status_code=400 request=)
```
(192.1.1.2 has been replaced to hide my super secret local ip)
Tried to search for anyone having the same issue but couldnt. Found this: https://github.com/getsentry/self-hosted/issues/1288#issuecomment-1047595368
And I ran:
`sudo docker exec -ti sentry-self-hosted-web-1 sentry permissions add -u mymail@mail.com -p "users.admin"`
`Added permission `users.admin` to mymail@mail.com`
Restarted the containers. Still the same result.
NOTE: Please DO NOT transfer this issue to self-hosted as the people from self-hosted said this is not something you can fix on self-hosted alone.
Help is appreciated.
Contributor guide
Research direction
Reproduce the upgrade with Google Auth and inspect the reported PUT requests to /api/0/internal/options/ and /api/0/auth/. Start with the logged AuthenticatorIndexEndpoint and AuthIndexEndpoint paths, then compare the superuser validation behavior with the documented Google Auth setup. Done means identifying the authentication mismatch and documenting or fixing a reproducible resolution.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose
- Domain
- api, authentication
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100