HunTorrent: IPv4-re kötött HTTP kliens a reCAPTCHA-zár ellen - #245
HunTorrent: IPv4-re kötött HTTP kliens a reCAPTCHA-zár ellen#245ntamas94 wants to merge 2 commits into
Conversation
A HunTorrent reCAPTCHA-számlálója IP alapú. Ha a szerver IPv6-on megy ki
(a getaddrinfo alapból az IPv6-ot preferálja globális IPv6 esetén), akkor a
kézi böngészős belépés (jellemzően IPv4) nem az app forgalmára oldja fel a
captchát, így az automata login véglegesen elakad ("Sikertelen bejelentkezés").
Az indexer az __init__-ben a saját HTTP kliensét IPv4-re kötött transporttal
építi újra (local_address="0.0.0.0"), így az app ugyanarról az IPv4 címről
megy ki, mint a böngésző — a kézi belépés feloldja a captchát az app számára is.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 425ad8bccd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| follow_redirects=True, | ||
| headers=base_client.headers, | ||
| timeout=base_client.timeout, | ||
| transport=httpx.AsyncHTTPTransport(local_address="0.0.0.0"), |
There was a problem hiding this comment.
Preserve proxy routing when forcing IPv4
In deployments that rely on HTTPS_PROXY/ALL_PROXY/NO_PROXY, this replacement client bypasses the proxy settings that the base AsyncClient honored by default: HTTPX disables environment proxy mounts whenever a custom transport is passed, so only HunTorrent traffic will suddenly connect directly instead of through the configured proxy. Please preserve the environment proxy mounts or add the IPv4-bound transport through the same proxy-aware configuration.
Useful? React with 👍 / 👎.
A bejelentkezés eddig némán bukott el: a felületen csak "Sikertelen bejelentkezés" látszott, a logban semmi. Így nem derült ki, hogy a HunTorrent reCAPTCHA-t kapcsolt-e be (amit az automata login nem tud megoldani), vagy tényleg rossz a jelszó. - ha a bejelentkező oldalon reCAPTCHA van, warning szintű log figyelmeztet, hogy egyszer kézzel, böngészőből kell belépni ugyanarról az IP-ről, - a bejelentkezés eredményét naplózzuk: hiba warning, siker info szinten. A jelszó soha nem kerül logba, csak a felhasználónév. Warning szint, mert prod módban az uvicorn log_level="warning", tehát ott is látszik. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Köszi, a #246-os konténer szintű megoldás ( A glibc precedencia-állítás globálisan és tisztán oldja meg, hogy az app IPv4-en menjen ki, így a kézi böngészős belépés ugyanarra az IP-re oldja fel a reCAPTCHA-t. Nálam éles szerveren igazolt volt, hogy az IPv6-os egress volt a gond (a stremhu Zárom ezt a PR-t. A benne lévő bejelentkezés-naplózás (reCAPTCHA-zár jelzése + login eredmény) viszont önmagában is hasznos, azt átvittem a #247-be, IPv4-mentesen. |
Probléma
A HunTorrent reCAPTCHA-számlálója IP alapú. Ha a szerver IPv6-on megy ki (a
getaddrinfoglobális IPv6 esetén alapból az IPv6-ot preferálja), akkor a kézi böngészős belépés (IPv4) nem az app forgalmára oldja fel a captchát — így az automata_loginvéglegesen elakad:AuthenticationException: Sikertelen bejelentkezés a(z) HunTorrent fiókba..Élő szerveren ellenőrizve: a stremhu
2001:...(IPv6) forrás IP-ről ment ki, a böngésző IPv4-ről → a HunTorrent két külön IP-t látott, a kézi belépés nem oldotta fel a captchát az app forgalmára.Megoldás
Az indexer az
__init__-ben a sajátIndexerClient-jét IPv4-re kötött transporttal építi újra (httpx.AsyncHTTPTransport(local_address="0.0.0.0")), a base kliens fejléceit/timeout-ját és cookie-jait átvéve. Így az app ugyanarról az IPv4 címről megy ki, mint a böngésző.IndexerClientimportálható).extra_hosts/DNS hackre.huntorrent.py-t érinti (+20 sor), a keresés/parse logikát nem.