Skip to content

HunTorrent: IPv4-re kötött HTTP kliens a reCAPTCHA-zár ellen - #245

Closed
ntamas94 wants to merge 2 commits into
s4pp1:mainfrom
ntamas94:fix/huntorrent-ipv4-upstream
Closed

HunTorrent: IPv4-re kötött HTTP kliens a reCAPTCHA-zár ellen#245
ntamas94 wants to merge 2 commits into
s4pp1:mainfrom
ntamas94:fix/huntorrent-ipv4-upstream

Conversation

@ntamas94

Copy link
Copy Markdown
Contributor

Probléma

A HunTorrent reCAPTCHA-számlálója IP alapú. Ha a szerver IPv6-on megy ki (a getaddrinfo globá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 _login vé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át IndexerClient-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ő.

  • Nem igényel base class módosítást (az IndexerClient importálható).
  • Nincs szükség host oldali extra_hosts/DNS hackre.
  • Csak a huntorrent.py-t érinti (+20 sor), a keresés/parse logikát nem.

Megjegyzés: a poster-grid parse-javítás külön PR-ben megy (#244), ez a PR attól független, közvetlenül a main-re alapozva.

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>

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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"),

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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>
@ntamas94

Copy link
Copy Markdown
Contributor Author

Köszi, a #246-os konténer szintű megoldás (precedence ::ffff:0:0/96 100 a /etc/gai.conf-ba) jobb, mint ez a PR — igazad van, itt elég durván felül volt ütve a kliens transportja indexer szinten.

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 2001:... forrás IP-ről ment, a böngésző IPv4-ről), szóval a #246 pont a gyökérokot kezeli.

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.

@ntamas94 ntamas94 closed this Jul 24, 2026
@ntamas94
ntamas94 deleted the fix/huntorrent-ipv4-upstream branch July 24, 2026 05:53
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.

1 participant