feat(vote): add ipify as an alternative IP correlation adapter#126
Open
IbanEtchep wants to merge 1 commit into
Open
feat(vote): add ipify as an alternative IP correlation adapter#126IbanEtchep wants to merge 1 commit into
IbanEtchep wants to merge 1 commit into
Conversation
The "IPv4/IPv6 compatibility" feature has always relied on a client-side trick:
the page loads ipv6-adapter.com's /v1/api.js, which makes two requests to
v4-only and v6-only dedicated hostnames on their CDN, revealing both of the
player's IPs to their backend. The backend stores the correlation in a DB
that the plugin then queries via /api/v1/fetch?ip=X during verification.
That dependency is currently broken: Cloudflare flagged cdn.ipv6-adapter.com
as malware (likely a false positive on the fingerprint-style request pattern),
making the script unloadable for every player regardless of their network.
With the script blocked, no correlation is registered, so /fetch?ip=X returns
"Unknown IP address" for everyone — and IPv6-native players fail verification
on vote sites that record IPv4 only (or vice versa).
This adds ipify.org as an alternative adapter using the exact same client-side
mechanism without the third-party correlation backend:
api.ipify.org → A record only, forces IPv4, browser reveals IPv4
api6.ipify.org → AAAA record only, forces IPv6, browser reveals IPv6
The two discovered IPs are written to short-lived cookies that VoteVerifier
reads during the verification step. The full IP list (request IP + cookie
IPs) is then passed to each vote site's API exactly as before.
== Settings ==
A new "IP correlation adapter" radio appears under the existing "Enable
IPv4/IPv6 compatibility" toggle. Two options:
- ipv6-adapter.com (default, retro-compatible) — unchanged behavior
- ipify.org — recommended fallback while ipv6-adapter remains blocked
== Security ==
Cookie IPs are validated with FILTER_VALIDATE_IP plus NO_PRIV_RANGE /
NO_RES_RANGE flags so a tampered cookie cannot smuggle in a private or
reserved address.
== Theme compatibility ==
The script-loading logic (which adapter to load, vote.js URL, username
injection) lives in a new partial: resources/views/partials/scripts.blade.php.
The plugin's default vote::index includes it via:
@Push('scripts')
@include('vote::partials.scripts')
@endpush
Themes that fully override vote::index (which most do) should switch their
hardcoded @Push('scripts') block to the same @include call. This is the
only change theme authors need to make — future adapter additions or
behavior tweaks happen in the partial without touching themes again.
Themes that don't update keep working: they continue to hardcode the
ipv6-adapter script as before. They just don't get the new ipify option
until they include the partial.
Closes a real production regression observed in May 2026 where every vote
attempt against IPv4-only vote sites failed for IPv6-native players after
Cloudflare flagged the ipv6-adapter CDN.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ipv6-adapter.com dependency is currently broken: Cloudflare flagged cdn.ipv6-adapter.com as malware, making the script unloadable for every player. With the script blocked, no correlation is registered, so /fetch?ip=X returns "Unknown IP address" for everyone — and IPv6-native players fail verification on vote sites that record IPv4 only (or vice versa).
This adds ipify.org as an alternative adapter using the exact same client-side mechanism without the third-party correlation backend:
api.ipify.org → A record only, forces IPv4, browser reveals IPv4
api6.ipify.org → AAAA record only, forces IPv6, browser reveals IPv6
The two discovered IPs are written to short-lived cookies that VoteVerifier reads during the verification step. The full IP list (request IP + cookie IPs) is then passed to each vote site's API exactly as before.
== Settings ==
A new "IP correlation adapter" radio appears under the existing "Enable IPv4/IPv6 compatibility" toggle. Two options:
== Security ==
Cookie IPs are validated with FILTER_VALIDATE_IP plus NO_PRIV_RANGE / NO_RES_RANGE flags so a tampered cookie cannot smuggle in a private or reserved address.
== Theme compatibility ==
The script-loading logic (which adapter to load, vote.js URL, username injection) lives in a new partial: resources/views/partials/scripts.blade.php.
The plugin's default vote::index includes it via:
Themes that fully override vote::index (which most do) should switch their hardcoded @Push('scripts') block to the same @include call. This is the only change theme authors need to make — future adapter additions or behavior tweaks happen in the partial without touching themes again.
Themes that don't update keep working: they continue to hardcode the ipv6-adapter script as before. They just don't get the new ipify option until they include the partial.