getsentry / getsentry/sentry

CPU/RAM Usage Requires superuser classic auth

Open
#107,593 6 comments 0 reactions 0 assignees View on GitHub
Bug Self-hosted
Dominant language
Python
Stars
44.8k
Forks
4.9k
Avg merge
22h 21m
Merged PRs (30d)
586

Description

### Self-Hosted Version

25.11.0

### CPU Architecture

x86 64

### Docker Version

podman 4.9.4-rhel

### Docker Compose Version

podman-compose version 1.5.0

### Machine Specification

- [x] My system meets the minimum system requirements of Sentry

### Steps to Reproduce
```bash
export http_proxy=*****
export https_proxy=*****

export no_proxy=smtp,memcached,redis,postgres,pgbouncer,kafka,clickhouse,seaweedfs,snuba-api,symbolicator,web,worker,nginx,relay,vroom,taskbroker,172.17.0.0/16,127.0.0.0/8

umask 0002

git clone https://github.com/getsentry/self-hosted.git
cd self-hosted
git checkout 25.11.0
#podman not support --wait
sed -i 's/$dc up --wait seaweedfs postgres/$dc up -d seaweedfs postgres; sleep 30/' install/bootstrap-s3-nodestore.sh

#we have a problem with this condition
sed -i "s,) != 's3://nodestore', | tr -d '[:space:]') != 's3://nodestore'," install/bootstrap-s3-nodestore.sh
export CONTAINER_ENGINE_PODMAN=1 REPORT_SELF_HOSTED_ISSUES=0
./install.sh
echo 'system.url-prefix: https://sentry.xxx.xxx >> sentry/config.yml
echo -e 'CSRF_TRUSTED_ORIGINS = ["https://sentry.xxx.xxxx"]\nSENTRY_AIR_GAP = True\nSENTRY_BEACON = False' >> sentry/sentry.conf.py
echo -e "SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')\nUSE_X_FORWARDED_HOST = True\nSESSION_COOKIE_SECURE = True\nCSRF_COOKIE_SECURE = True\nSOCIAL_AUTH_REDIRECT_IS_HTTPS = True" >> sentry/sentry.conf.py
podman compose --profile=feature-complete up --force-recreate -d
```
I open my browser and enter the URL to access the interface.
I enter my credentials and log in.
I click on the button 'No, I'd prefer to keep CPU/RAM usage private' in the 'CPU/RAM Usage' popup.
A 'No, I'd prefer to keep CPU/RAM usage private' popup appears asking for my superuser password. I fill it in with my password.

Image

### Expected Result

Once I enter the password, I can start my onboarding.

### Actual Result

When I click the 'Continue' button after selecting 'No, I'd prefer to keep CPU/RAM usage private,' a request is sent to /api/0/internal/options/, and I receive a 403 with the following response:

```json
{
"detail": {
"code": "superuser-required",
"message": "You need to re-authenticate for superuser.",
"extra": {}
},
"code": "superuser-required",
"extra": {},
"message": "You need to re-authenticate for superuser."
}
```

However, when the next popup prompts me for my password and I enter it, a request is sent to /api/0/auth/ and I receive a 200 response, indicating that I have the required permissions, as shown in the image below.

Image
Image

### Event ID

_No response_

Contributor guide

Open the contributing guide

Research direction

Trace the onboarding CPU/RAM Usage flow from the /api/0/internal/options/ request and the subsequent /api/0/auth/ password re-authentication request. Compare how the successful authentication response is used by the options request, using the reported 403 response as the failing behavior. Done means selecting private CPU/RAM usage and completing re-authentication allows onboarding to continue.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, authentication, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.