Skip to content

fix(gitea): allow opted-in private network access - #253

Merged
l1shen merged 1 commit into
oomol-lab:mainfrom
wi1shu7:main
Aug 2, 2026
Merged

fix(gitea): allow opted-in private network access#253
l1shen merged 1 commit into
oomol-lab:mainfrom
wi1shu7:main

Conversation

@wi1shu7

@wi1shu7 wi1shu7 commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

Summary

  • wire the Gitea executor, proxy, credential validation, and base URL validation to the existing OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK opt-in
  • allow trusted self-hosted Gitea instances on private LAN, CGNAT/Tailscale, and private hostnames when explicitly enabled
  • allow plain HTTP instance URLs only when private-network access is enabled
  • preserve guarded DNS and redirect validation, including targets that remain blocked regardless of the opt-in
  • document the Gitea deployment requirement and add focused regression coverage

Why

Gitea is commonly self-hosted on a LAN or an overlay network such as Tailscale.

Before this change, setting:

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK=true

did not affect the Gitea provider. Its base URL validation and request paths remained public-only, so instance URLs such as http://192.168.1.10:3000 or hostnames resolving to private addresses were still rejected.

This change applies the existing deployment-level opt-in consistently across:

  • credential validation
  • action execution
  • proxy requests
  • Gitea base URL normalization

Security behavior

The default behavior is unchanged: private and plain HTTP targets remain blocked unless the deployment explicitly enables private-network access.

When enabled:

  • DNS-resolved address validation remains active
  • redirects continue to be validated by the guarded fetch implementation
  • loopback, link-local, cloud metadata, and other always-blocked targets remain rejected
  • the opt-in applies only to the configured Gitea instance base URL

Private targets are only reachable from runtimes with network access to them, such as Node/Docker deployments. Enabling the flag does not make private addresses reachable from Cloudflare Workers.

Validation

  • npm run fix-check
  • npx vitest run src/providers/gitea/runtime.test.ts src/providers/gitea/executors.test.ts
  • full Vitest suite
  • GitHub Actions: lint, formatting check, typecheck, and tests

@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bbd3d6b5-8986-4464-a25a-b8fe9000a373

📥 Commits

Reviewing files that changed from the base of the PR and between 2420617 and 5dabe11.

📒 Files selected for processing (5)
  • docs/configuration.md
  • src/providers/gitea/definition.ts
  • src/providers/gitea/executors.test.ts
  • src/providers/gitea/executors.ts
  • src/providers/gitea/runtime.ts

Summary by CodeRabbit

  • New Features

    • Added support for connecting Gitea to private or overlay network targets when private-network access is enabled.
    • Documented the required self-hosted runtime setting for private-network and plain HTTP Gitea connections.
  • Bug Fixes

    • Improved Gitea URL handling and request validation for private, reserved, loopback, cloud-metadata, and HTTP targets.
    • Continued allowing standard public HTTPS connections by default.

Walkthrough

Gitea now supports opt-in access to private and overlay network targets. URL validation uses isPrivateNetworkAccessAllowed and permits plain HTTP only when private access is enabled. Executor, proxy, and credential validation requests use guarded fetchers. Documentation describes the required runtime setting. Tests cover public HTTPS, private targets, LAN HTTP, loopback, and cloud-metadata destinations.

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant GiteaExecutors
  participant createProviderFetch
  participant GiteaServer
  Client->>GiteaExecutors: validate credentials or execute request
  GiteaExecutors->>createProviderFetch: apply private-network policy
  createProviderFetch->>GiteaServer: send guarded request
  GiteaServer-->>GiteaExecutors: return response
  GiteaExecutors-->>Client: return validation or execution result
Loading

Possibly related PRs

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title follows the required format and accurately describes the Gitea private-network access change.
Description check ✅ Passed The description directly explains the Gitea private-network access changes, security behavior, documentation, and test coverage.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
✨ Simplify code
  • Create PR with simplified code

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@l1shen
l1shen merged commit cf19727 into oomol-lab:main Aug 2, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants