Woodpecker CI OAuth Login Loop Issue - Detailed Report

[dan3093]

Summary

Woodpecker CI successfully completes GitHub OAuth authentication and creates a session cookie, but the session cookie is not recognized on subsequent requests, resulting in an infinite login loop. The user exists in the database, the cookie is set with correct attributes and sent in all requests, but Woodpecker's session middleware does not validate/recognize it.

TL;DR for Maintainers

What works:

• ✓ OAuth flow completes successfully (GitHub → Woodpecker)
• ✓ User created in database correctly (user_id: 1, admin: true)
• ✓ Session cookie (user_sess) created with valid JWT payload
• ✓ Cookie stored by browser with correct attributes (HttpOnly, Secure, correct domain/path)
• ✓ Cookie sent in all subsequent requests (verified in Network tab)

What fails:

• ✗ Session cookie is never validated/recognized by Woodpecker
• ✗ No session validation attempts logged (even at WOODPECKER_LOG_LEVEL=trace)
• ✗ User shown as unauthenticated (WOODPECKER_USER = null) after successful OAuth
• ✗ Infinite redirect loop to /login

Environment:

• Woodpecker 2.8.3 (Docker)
• Behind Cloudflare → Nginx Proxy Manager → Woodpecker (HTTP)
• All proxy headers configured (X-Forwarded-Proto, X-Forwarded-For, X-Forwarded-Host)
• WOODPECKER_SECRET set for consistent JWT signing
• Multiple other services work fine on same proxy setup

Key observation: Complete absence of session validation log messages suggests the session middleware is not attempting to read/validate cookies in this reverse proxy configuration.

Author's Note

This report was prepared with the assistance of Claude (Anthropic's AI assistant) to ensure comprehensive documentation of the troubleshooting process.

While I am a fairly competent IT professional who successfully hosts a variety of services (including multiple containerized applications behind the same reverse proxy setup), I acknowledge that I could easily be overlooking something in my configuration. The complexity of this multi-layer proxy setup (Cloudflare → NPM → Woodpecker) introduces many potential points of failure, and despite my best efforts, there may be a simple configuration issue I've missed.

I've included extensive diagnostic information in this report to help identify whether this is a configuration issue on my end, a documentation gap, or a potential bug. I appreciate any guidance the maintainers can provide, and I'm happy to provide additional information or test potential fixes.

Request for Assistance

This issue requires Woodpecker maintainer expertise to diagnose. Possible next steps:

1. Identify if there are undocumented environment variables needed for proxy setups
2. Add debug logging to session middleware to show cookie validation attempts
3. Determine why session middleware is not processing cookies in this configuration
4. Provide guidance on proper configuration for multi-layer reverse proxy setups

---

Environment

Infrastructure

• Hosting: Unraid server
• Reverse Proxy Chain: Browser → Cloudflare (HTTPS) → Nginx Proxy Manager (HTTPS→HTTP) → Woodpecker (HTTP)
• Public URL: https://woodpecker.example.com
• Internal URL: http://192.168.x.x:8001

Software Versions

• Woodpecker Server: 2.8.3 (Docker image: woodpeckerci/woodpecker-server:latest)
• Woodpecker Agent: 2.8.3 (Docker image: woodpeckerci/woodpecker-agent:latest)
• Nginx Proxy Manager: Latest (Docker)
• Cloudflare: Full (strict) SSL mode with Origin Certificate
• Forge: GitHub OAuth App

Configuration

Docker Compose (docker-compose.woodpecker.yml)

version: '3'

services:
  woodpecker-server:
    image: woodpeckerci/woodpecker-server:latest
    container_name: woodpecker-server
    restart: unless-stopped
    ports:
      - "8001:8000"
      - "9000:9000"
    volumes:
      - /mnt/user/appdata/woodpecker-ci/server-data:/var/lib/woodpecker/
    environment:
      - WOODPECKER_OPEN=true
      - WOODPECKER_HOST=${WOODPECKER_HOST}
      - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
      - WOODPECKER_GITHUB=${WOODPECKER_GITHUB:-false}
      - WOODPECKER_GITHUB_CLIENT=${WOODPECKER_GITHUB_CLIENT}
      - WOODPECKER_GITHUB_SECRET=${WOODPECKER_GITHUB_SECRET}
      - WOODPECKER_ADMIN=${WOODPECKER_ADMIN}
      - WOODPECKER_SESSION_EXPIRES=72h
      - WOODPECKER_LOG_LEVEL=trace
      - WOODPECKER_SERVER_ADDR=:8000
      - WOODPECKER_SECRET=${WOODPECKER_SECRET}
    networks:
      - proxynet

  woodpecker-agent:
    image: woodpeckerci/woodpecker-agent:latest
    container_name: woodpecker-agent
    restart: unless-stopped
    depends_on:
      - woodpecker-server
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WOODPECKER_SERVER=woodpecker-server:9000
      - WOODPECKER_AGENT_SECRET=${WOODPECKER_AGENT_SECRET}
      - WOODPECKER_MAX_WORKFLOWS=4
      - WOODPECKER_HEALTHCHECK=true
      - WOODPECKER_LOG_LEVEL=info
      - WOODPECKER_BACKEND=docker
      - WOODPECKER_BACKEND_DOCKER_NETWORK=proxynet
    networks:
      - proxynet

networks:
  proxynet:
    external: true

volumes:
  woodpecker-server-data:
    driver: local

Environment Variables (.env)

WOODPECKER_HOST=https://woodpecker.example.com
WOODPECKER_AGENT_SECRET=<redacted-64-char-hex-string>
WOODPECKER_GITHUB=true
WOODPECKER_GITHUB_CLIENT=<redacted-github-client-id>
WOODPECKER_GITHUB_SECRET=<redacted-github-client-secret>
WOODPECKER_ADMIN=dan3093
WOODPECKER_MAX_WORKFLOWS=4
WOODPECKER_LOG_LEVEL=trace
WOODPECKER_SECRET=<redacted-64-char-hex-string>

GitHub OAuth App Configuration

• Application name: Woodpecker CI
• Homepage URL: https://woodpecker.example.com
• Authorization callback URL: https://woodpecker.example.com/authorize

Nginx Proxy Manager Configuration

Proxy Host Details:

• Domain: woodpecker.example.com
• Scheme: http
• Forward Hostname/IP: 192.168.x.x
• Forward Port: 8001
• Websockets Support: Enabled
• SSL Certificate: Cloudflare Origin Certificate
• Force SSL: Enabled

Custom Nginx Configuration (Advanced tab):

# Fix X-Forwarded-For
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# Required headers for OAuth
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

Generated NPM Config (actual configuration):

server {
  set $forward_scheme http;
  set $server         "192.168.x.x";
  set $port           8001;

  listen 80;
  listen [::]:80;
  listen 443 ssl;
  listen [::]:443 ssl;

  server_name woodpecker.example.com;
  http2 on;

  ssl_certificate /data/custom_ssl/npm-48/fullchain.pem;
  ssl_certificate_key /data/custom_ssl/npm-48/privkey.pem;

  proxy_set_header X-Forwarded-For $remote_addr;  # Note: This was later fixed in custom config
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Host $http_host;

  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $http_connection;
  proxy_http_version 1.1;

  include conf.d/include/force-ssl.conf;
  include conf.d/include/block-exploits.conf;

  location / {
    include conf.d/include/proxy.conf;
  }
}

Cloudflare Configuration

• SSL/TLS Mode: Full (strict)
• SSL Certificate: Cloudflare Origin Certificate (installed in NPM)
• Proxy Status: Enabled (orange cloud)
• DNS Record: woodpecker.example.com → A record → Server IP

Issue Description

Expected Behavior

1. User clicks "Login with GitHub" at https://woodpecker.example.com/login
2. Redirected to GitHub OAuth authorization page
3. User authorizes the application
4. GitHub redirects back to https://woodpecker.example.com/authorize?code=...
5. Woodpecker creates user session and sets user_sess cookie
6. User is redirected to Woodpecker UI as authenticated user
7. Subsequent requests include the user_sess cookie and user remains logged in

Actual Behavior

1. User clicks "Login with GitHub" ✓
2. Redirected to GitHub OAuth authorization page ✓
3. User authorizes the application ✓
4. GitHub redirects back to /authorize?code=... ✓
5. Woodpecker creates session cookie ✓
6. User is redirected to homepage ✓
7. Homepage shows as unauthenticated (WOODPECKER_USER = null) ✗
8. User is immediately redirected back to /login ✗
9. Infinite login loop ✗

Diagnostic Evidence

1. Session Cookie is Created

Browser Application tab shows cookie is set after OAuth:

Name: user_sess
Value: <redacted-jwt-token>
Domain: woodpecker.example.com
Path: /
Expires: 2026-05-17
HttpOnly: ✓
Secure: ✓
Size: 152 bytes

JWT payload decoded:

{
  "exp": 1763695751,
  "type": "sess",
  "user-id": "1"
}

2. Cookie is Sent in Subsequent Requests

Browser Network tab shows Cookie header in requests:

Cookie: user_sess=<redacted-jwt-token>

3. User Exists in Database

sqlite3 /mnt/user/appdata/woodpecker-ci/server-data/woodpecker.sqlite "SELECT * FROM users;"

Output:

1|1|<user-id>|dan3093|<redacted-github-token>|0|<redacted-email>|https://avatars.githubusercontent.com/u/<user-id>?v=4|1|<redacted-api-token>|1

User record shows:

• user_id: 1
• user_login: dan3093
• user_admin: 1 (is admin)
• User was successfully created during OAuth

4. Woodpecker Logs (Trace Level)

OAuth flow completes successfully:

{"level":"trace","message":"[GET] /authorize?forgeId=1"}
{"level":"debug","method":"GET","path":"/authorize","status":303}
{"level":"trace","message":"[GET] /authorize?code=...&state=..."}
{"level":"debug","method":"GET","path":"/authorize","status":303}
{"level":"trace","message":"[GET] /"}
{"level":"debug","method":"GET","path":"/","status":200}

Critical observation: No log messages about:

• Session validation
• JWT parsing
• Cookie recognition
• User authentication attempts

Even with WOODPECKER_LOG_LEVEL=trace, there are zero log entries indicating the session middleware is attempting to validate the cookie.

5. Homepage Shows No User

After OAuth redirect, page source shows:

window.WOODPECKER_USER = null;  // Not logged in!
window.WOODPECKER_CSRF = "";
window.WOODPECKER_VERSION = "2.8.3";

6. No Errors in Logs

Woodpecker container is healthy and stable:

• No crashes
• No panics
• No error messages
• Healthchecks passing (/healthz returns 204)
• No database errors

Troubleshooting Steps Attempted

1. Proxy Header Configuration ✓

• Added X-Forwarded-Proto, X-Forwarded-For, X-Forwarded-Host, X-Real-IP headers
• Fixed NPM's incorrect X-Forwarded-For implementation ($remote_addr → $proxy_add_x_forwarded_for)
• Enabled WebSocket support
• Verified headers are being passed through proxy chain

2. Secret Management ✓

• Added WOODPECKER_SECRET environment variable with strong random value
• Ensures consistent JWT signing across container restarts
• Restarted containers after adding

3. Server Configuration ✓

• Added WOODPECKER_SERVER_ADDR=:8000
• Set WOODPECKER_LOG_LEVEL=trace for maximum verbosity
• Configured WOODPECKER_SESSION_EXPIRES=72h

4. SSL/TLS Configuration ✓

• Cloudflare: Full (strict) mode
• Installed Cloudflare Origin Certificate in NPM
• Verified SSL chain is valid
• Force SSL enabled in NPM

5. Network Configuration ✓

• Both NPM and Woodpecker on proxynet Docker network
• NPM connects to Woodpecker via http://192.168.x.x:8001
• Cloudflare proxy enabled (orange cloud)

6. OAuth Configuration ✓

• GitHub callback URL matches exactly: https://woodpecker.example.com/authorize
• No trailing slashes
• HTTPS protocol specified
• Client ID and secret are correct (OAuth flow succeeds)

7. Database Verification ✓

• User record exists and is correctly populated
• User is marked as admin
• OAuth token is stored

8. Cookie Analysis ✓

• Cookie domain matches site domain
• Cookie path is / (covers all routes)
• HttpOnly and Secure flags are set correctly
• Cookie is not expired
• Cookie size is normal (152 bytes)

Network Analysis

HAR File Analysis

From captured HAR file:

• No Set-Cookie headers found in responses during first OAuth attempt
• Cookie appears to be set via different mechanism
• All subsequent requests include Cookie: user_sess=... header
• No cookie-related errors in browser console

NPM Error Logs

upstream prematurely closed connection while reading upstream
  → Normal for SSE endpoints (/api/stream/events)

connect() failed (111: Connection refused)
  → Occasional connection issues, but not consistent

Potential Root Causes

1. Session Middleware Not Reading Cookies

• Most likely cause based on evidence
• No session validation attempts in logs despite cookie being sent
• Suggests middleware is not configured to read/trust cookies in this proxy setup

2. JWT Secret Mismatch (Ruled Out)

• WOODPECKER_SECRET is now set and consistent
• New sessions created after setting secret still fail

3. Proxy Header Trust Issues (Unlikely)

• Headers are configured correctly
• IP addresses in logs show proper forwarding ( = Cloudflare IP)
• But session validation never attempts, so headers may not be the issue

4. Cookie Domain/Path Mismatch (Ruled Out)

• Cookie domain matches exactly
• Cookie path is /
• No browser warnings or errors

5. SameSite Cookie Attribute (Unknown)

• SameSite attribute not visible in browser dev tools
• Could be causing cookies to not be sent in certain contexts
• But Network tab shows cookie IS being sent

6. Database Session Storage Issue (Unlikely)

• User record exists and is valid
• No database errors in logs
• But session validation never attempts to query database

Configuration Gaps

Potentially Missing Environment Variables

The following environment variables were NOT set (may or may not be relevant):

• WOODPECKER_BEHIND_PROXY - May be needed to enable proxy mode
• WOODPECKER_COOKIE_SECURE - Explicit cookie security setting
• WOODPECKER_COOKIE_SAMESITE - SameSite attribute control
• WOODPECKER_PROXY_PASS_HEADER - Enable proxy header trust
• Any cookie domain or session-specific variables

These variables are not documented in Woodpecker's environment variable documentation, so their existence/necessity is unknown.

Conclusion

This issue represents a session validation failure in Woodpecker CI when deployed behind a complex reverse proxy setup (Cloudflare → Nginx Proxy Manager → Woodpecker).

Key facts:

1. ✓ OAuth authentication completes successfully
2. ✓ User is created in database correctly
3. ✓ Session cookie is created with correct attributes
4. ✓ Cookie is stored by browser and sent in all requests
5. ✓ All proxy headers are configured correctly
6. ✓ Woodpecker server is healthy and stable
7. ✗ Session cookie is never validated/recognized

The complete absence of session validation log messages (even at trace level) suggests Woodpecker's session middleware is not attempting to read or validate cookies in this configuration. This may indicate:

• A missing/undocumented configuration requirement for proxy setups
• A bug in the session middleware with certain proxy configurations
• An incompatibility with this specific version (2.8.3)
• A requirement for additional environment variables not found in documentation

Additional Information

• Issue affects fresh installation
• No custom code or modifications
• All components using latest/official Docker images
• Multiple independent troubleshooting efforts over several hours

---

Report generated: 2025-11-18
Woodpecker version: 2.8.3
Setup type: Docker Compose on Unraid

[anbraten]

Thanks for the detailed report. Could you update to the latest Woodpecker version? Is the Cookie header not forwarded by your reverse proxies?

[qwerty287]

closing as no response from opener

[jefc1111]

Hi there, I am getting the same sort of behaviour with Bitbucket forge: OAuth link works, but I end up not logged in on the Wood pecker side, so it manifests as an infinite loop to /login.

I have tried many of the same troubleshooting steps and was wondering if you did find a solution.