# Dev Container Bugsink Setup

Local Bugsink instance for development - NOT connected to production.

## Quick Reference

| Item         | Value                                                       |
| ------------ | ----------------------------------------------------------- |
| UI           | `https://localhost:8443` (nginx proxy from 8000)            |
| Credentials  | `admin@localhost` / `admin`                                 |
| Projects     | Backend (Dev) = Project ID 1, Frontend (Dev) = Project ID 2 |
| Backend DSN  | `SENTRY_DSN=http://<key>@localhost:8000/1`                  |
| Frontend DSN | `VITE_SENTRY_DSN=http://<key>@localhost:8000/2`             |

## Configuration Files

| File              | Purpose                                                           |
| ----------------- | ----------------------------------------------------------------- |
| `compose.dev.yml` | Initial DSNs using `127.0.0.1:8000` (container startup)           |
| `.env.local`      | **OVERRIDES** compose.dev.yml with `localhost:8000` (app runtime) |

**CRITICAL**: `.env.local` takes precedence over `compose.dev.yml` environment variables.

## Why localhost vs 127.0.0.1?

The `.env.local` file uses `localhost` while `compose.dev.yml` uses `127.0.0.1`. Both work in practice - `localhost` was chosen when `.env.local` was created separately.

## HTTPS Setup

- Self-signed certificates auto-generated with mkcert on container startup
- CSRF Protection: Django configured with `CSRF_TRUSTED_ORIGINS` for both `localhost` and `127.0.0.1` (see below)
- HTTPS proxy: nginx on port 8443 proxies to Bugsink on port 8000
- HTTPS is for UI access only - Sentry SDK uses HTTP directly

### CSRF Configuration

Django 4.0+ requires `CSRF_TRUSTED_ORIGINS` for HTTPS POST requests. The Bugsink configuration (`Dockerfile.dev`) includes:

```python
CSRF_TRUSTED_ORIGINS = [
    "https://localhost:8443",
    "https://127.0.0.1:8443",
    "http://localhost:8000",
    "http://127.0.0.1:8000",
]
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
```

**Both hostnames are required** because browsers treat `localhost` and `127.0.0.1` as different origins.

If you get "CSRF verification failed" errors, see [BUGSINK-SETUP.md](tools/BUGSINK-SETUP.md#csrf-verification-failed) for troubleshooting.

## Isolation Benefits

- Dev errors stay local, don't pollute production/test dashboards
- No Gitea secrets needed - everything self-contained
- Independent testing of error tracking without affecting metrics

## Accessing Errors

### Via Browser

1. Open `https://localhost:8443`
2. Login with credentials above
3. Navigate to Issues to view captured errors

### Via MCP (bugsink-dev)

Configure in `.claude/mcp.json`:

```json
{
  "bugsink-dev": {
    "command": "node",
    "args": ["d:\\gitea\\bugsink-mcp\\dist\\index.js"],
    "env": {
      "BUGSINK_URL": "http://localhost:8000",
      "BUGSINK_API_TOKEN": "<token-from-local-bugsink>",
      "BUGSINK_ORG_SLUG": "sentry"
    }
  }
}
```

**Get auth token**:

API tokens must be created via Django management command (Bugsink 2.0.11 does not have a "Settings > API Keys" UI):

```bash
podman exec flyer-crawler-dev sh -c 'cd /opt/bugsink/conf && \
  DATABASE_URL=postgresql://bugsink:bugsink_dev_password@postgres:5432/bugsink \
  SECRET_KEY=dev-bugsink-secret-key-minimum-50-characters-for-security \
  DJANGO_SETTINGS_MODULE=bugsink_conf \
  PYTHONPATH=/opt/bugsink/conf:/opt/bugsink/lib/python3.10/site-packages \
  /opt/bugsink/bin/python -m django create_auth_token'
```

This will output a 40-character lowercase hex token. Copy it to your MCP configuration.

**MCP Tools**: Use `mcp__bugsink-dev__*` tools (not `mcp__bugsink__*` which connects to production).