ai-tools/private-proxy-mcp

Watch

Fork 0

Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen #20

New issue

Closed

opened 2026-07-17 11:56:55 +02:00 by frank · 1 comment

frank commented

2026-07-17 11:56:55 +02:00

Owner

Ziel

Der aufrufende Agent kann pro HTTP-Request auswählen, als welcher erlaubte Client sich der private Proxy gegenüber dem Zielserver präsentiert.

Scope

Die MCP-Tools http_get und http_request erhalten einen optionalen Parameter client_profile.
Der Agent wählt ausschließlich aus serverseitig konfigurierten und in der Toolbeschreibung sichtbaren Profilnamen.
Mitgelieferte Basisprofile mindestens:
- default
- chrome-desktop
- firefox-desktop
- mobile-chrome
Ein Profil bündelt konsistente HTTP-Merkmale:
- User-Agent
- Accept
- Accept-Language
- Accept-Encoding
- passende Client-Hints wie Sec-CH-UA und Sec-CH-UA-Mobile
Betreiber können eigene Profile in der Viper-Konfiguration definieren und erlaubte Profile begrenzen.
Explizite Request-Header dürfen ein Profil nur gemäß bestehender Header-Policy überschreiben.
Authorization, Cookie, Host, Connection und weitere sensible beziehungsweise Hop-by-hop Header bleiben von Profilen ausgeschlossen.
Das Tool-Ergebnis nennt das effektiv verwendete Profil und nicht dessen sensitive Konfigurationsdetails.
Dokumentieren, dass ein Go-http.Client durch Header allein keinen echten Chrome-/Firefox-TLS-Fingerprint erzeugt. Wenn eine konsistente Browser-/TLS-Identität erforderlich ist, muss der Request über das Browser-Backend laufen.
Optional prüfen, ob ein kompatibles Profil an yt-dlp --impersonate weitergereicht werden kann; nur gegen eine Allowlist und nur wenn das installierte yt-dlp die Zielidentität unterstützt.
Profile und Browser-Versionen kontrolliert aktualisieren; keine behaupteten Versionsnummern dauerhaft fest codieren.

Sicherheits- und Datenschutzgrenzen

Die Auswahl darf keine Authentisierung umgehen und keine Cookies anderer Profile oder Benutzer übernehmen.
Logging enthält nur den Profilnamen; sensible Headerwerte werden weiterhin redigiert.
Profile sind eine Kompatibilitätsfunktion und keine Garantie zur Umgehung von Bot-Schutz.
Rate Limits, SSRF-Policy und Ziel-Allow-/Deny-Regeln gelten unverändert.

Akzeptanzkriterien

tools/list dokumentiert die erlaubten Profilnamen und Semantik.
Ohne client_profile bleibt das bisherige Default-Verhalten erhalten.
Integrationstests bestätigen die effektiven Header für jedes Basisprofil.
Tests verhindern widersprüchliche Client-Hints und gesperrte Header.
Ein unbekanntes oder nicht erlaubtes Profil erzeugt einen handlungsfähigen Tool Execution Error.
Dokumentation erklärt klar den Unterschied zwischen Headerprofil und echter Browser-/TLS-Emulation.

Abhängigkeiten

HTTP-Ausführungsengine
MCP-Webrequest-Tools
Netzwerk-/Header-Policy

Referenzen

yt-dlp unterstützt optionale Client-Impersonation: https://github.com/yt-dlp/yt-dlp#network-options
Browser Use wird in einem separaten Feature-Issue umgesetzt.

## Ziel Der aufrufende Agent kann pro HTTP-Request auswählen, als welcher erlaubte Client sich der private Proxy gegenüber dem Zielserver präsentiert. ## Scope - Die MCP-Tools http_get und http_request erhalten einen optionalen Parameter client_profile. - Der Agent wählt ausschließlich aus serverseitig konfigurierten und in der Toolbeschreibung sichtbaren Profilnamen. - Mitgelieferte Basisprofile mindestens: - default - chrome-desktop - firefox-desktop - mobile-chrome - Ein Profil bündelt konsistente HTTP-Merkmale: - User-Agent - Accept - Accept-Language - Accept-Encoding - passende Client-Hints wie Sec-CH-UA und Sec-CH-UA-Mobile - Betreiber können eigene Profile in der Viper-Konfiguration definieren und erlaubte Profile begrenzen. - Explizite Request-Header dürfen ein Profil nur gemäß bestehender Header-Policy überschreiben. - Authorization, Cookie, Host, Connection und weitere sensible beziehungsweise Hop-by-hop Header bleiben von Profilen ausgeschlossen. - Das Tool-Ergebnis nennt das effektiv verwendete Profil und nicht dessen sensitive Konfigurationsdetails. - Dokumentieren, dass ein Go-http.Client durch Header allein keinen echten Chrome-/Firefox-TLS-Fingerprint erzeugt. Wenn eine konsistente Browser-/TLS-Identität erforderlich ist, muss der Request über das Browser-Backend laufen. - Optional prüfen, ob ein kompatibles Profil an yt-dlp --impersonate weitergereicht werden kann; nur gegen eine Allowlist und nur wenn das installierte yt-dlp die Zielidentität unterstützt. - Profile und Browser-Versionen kontrolliert aktualisieren; keine behaupteten Versionsnummern dauerhaft fest codieren. ## Sicherheits- und Datenschutzgrenzen - Die Auswahl darf keine Authentisierung umgehen und keine Cookies anderer Profile oder Benutzer übernehmen. - Logging enthält nur den Profilnamen; sensible Headerwerte werden weiterhin redigiert. - Profile sind eine Kompatibilitätsfunktion und keine Garantie zur Umgehung von Bot-Schutz. - Rate Limits, SSRF-Policy und Ziel-Allow-/Deny-Regeln gelten unverändert. ## Akzeptanzkriterien - tools/list dokumentiert die erlaubten Profilnamen und Semantik. - Ohne client_profile bleibt das bisherige Default-Verhalten erhalten. - Integrationstests bestätigen die effektiven Header für jedes Basisprofil. - Tests verhindern widersprüchliche Client-Hints und gesperrte Header. - Ein unbekanntes oder nicht erlaubtes Profil erzeugt einen handlungsfähigen Tool Execution Error. - Dokumentation erklärt klar den Unterschied zwischen Headerprofil und echter Browser-/TLS-Emulation. ## Abhängigkeiten - HTTP-Ausführungsengine - MCP-Webrequest-Tools - Netzwerk-/Header-Policy ## Referenzen - yt-dlp unterstützt optionale Client-Impersonation: https://github.com/yt-dlp/yt-dlp#network-options - Browser Use wird in einem separaten Feature-Issue umgesetzt.

frank added this to the v0.5.0 – Extended Proxy Capabilities milestone

2026-07-17 11:57:16 +02:00

frank added the

labels

2026-07-17 11:57:16 +02:00

frank added a new dependency

2026-07-17 11:57:48 +02:00

#8 Begrenzte HTTP-Ausführungsengine im privaten Proxy implementieren

frank added a new dependency

2026-07-17 11:57:48 +02:00

#9 MCP-Tools http_get und http_request bereitstellen

frank added a new dependency

2026-07-17 11:57:48 +02:00

#10 Netzwerk-Policy und SSRF-Schutz für Webrequests umsetzen

codex was assigned by frank

2026-07-17 14:04:40 +02:00

frank commented

2026-07-17 14:27:06 +02:00

Author

Owner

🤖 forge agent started

Agent: codex
Model: gpt-5.6-sol
Mode: pr
Trigger: assignee=agent|+5 mapped

Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen — Der aufrufende Agent kann pro HTTP-Request auswählen, als welcher erlaubte Client sich der private Proxy gegenüber dem Zielserver präsentiert.

🤖 **forge agent started** - Agent: `codex` - Model: `gpt-5.6-sol` - Mode: `pr` - Trigger: `assignee=agent|+5 mapped` Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen — Der aufrufende Agent kann pro HTTP-Request auswählen, als welcher erlaubte Client sich der private Proxy gegenüber dem Zielserver präsentiert.

frank added the

agent:working

label

2026-07-17 14:27:06 +02:00

~~frank referenced this issue 2026-07-17 14:27:08 +02:00~~

fix: #20 Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen #30

frank referenced this issue

2026-07-17 14:27:08 +02:00

fix: #20 Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen #30

frank referenced this issue from a pull request that will close it,

2026-07-17 14:39:14 +02:00

fix: #20 Request-Identitätsprofile pro Proxy-Aufruf auswählbar machen #30