You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This isn't a bug or a request so much as something interesting I learned today while working on the Conjure integration with Tor.
I was debugging why connections to phantom IP addresses that were obtained from our domain fronted registrations were failing, while connections to phantom IPs from non domain-fronted registrations were working just fine. I noticed this in the CDN77 documentation:
X-Forwarded-For + X-Real-IP: This is the IP Address from the TCP connection from which our CDN Edge server received the request. To protect users’ personal data, we anonymize the last octet in the IP and replace it with a trailing zero. For example, if the IP address received from the TCP connection was 192.1.1.1, the anonymized IP will be 192.1.1.0.
This means Conjure's registration api will receive connections seemingly from these "anonymized" IP addresses, forward this to the detector, and the detector will see incoming TCP connections from the client's real IP address, and won't recognize them as phantom sessions.
I don't think there is much to do here, but I wanted to document it somewhere in case someone else came across the same issue.
The text was updated successfully, but these errors were encountered:
This isn't a bug or a request so much as something interesting I learned today while working on the Conjure integration with Tor.
I was debugging why connections to phantom IP addresses that were obtained from our domain fronted registrations were failing, while connections to phantom IPs from non domain-fronted registrations were working just fine. I noticed this in the CDN77 documentation:
This means Conjure's registration api will receive connections seemingly from these "anonymized" IP addresses, forward this to the detector, and the detector will see incoming TCP connections from the client's real IP address, and won't recognize them as phantom sessions.
I don't think there is much to do here, but I wanted to document it somewhere in case someone else came across the same issue.
The text was updated successfully, but these errors were encountered: