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
I'm wondering if there is a reason that the WebHelper function GetCurrentIpAddress() uses MapToIpv4() on all IP addresses?
I've built a plugin that uses IP Quality Score's API to check user's IP addresses and when users connect with IPv6, the MapToIPv4() function translates them into nonsensical IPv4 address, like 0.0.0.9 (obviously invalid) or 250.204.72.95 (reserved IP space, not used), neither of which are valid IPv4 addresses.
in the database:
ActivityLog.IpAddress is varchar(200)
Customer.LastIpAddress is longtext
ForumPost.IPAddress is varchar(100)
Log.IpAddress is varchar(200)
Order.CustomerIp is longtext
I'm not sure if there are others, but considering these entities as example, i highly doubt any entities were made with an IP property specifically long enough for IPv4 (15 characters.)
The longest an IPv6 address can be is 39 characters. Or in the worst, highly unlikely, case IPv4 mapped to IPv6, it can be 45 characters long. So, even this shouldn't produce a problem for the given database entities.
I could see a change to this possibly making problems for plugins expecting an IPv4 address - but they should be compensating for that on their own if they require it.
The text was updated successfully, but these errors were encountered:
Hi @danFbach. I looked at the implementation of the MapToIpv4 method and agree with you that such an operation is not capable of giving any real result. Thank you for your help
nopCommerce version: 4.6.3
I'm wondering if there is a reason that the WebHelper function GetCurrentIpAddress() uses MapToIpv4() on all IP addresses?
I've built a plugin that uses IP Quality Score's API to check user's IP addresses and when users connect with IPv6, the MapToIPv4() function translates them into nonsensical IPv4 address, like 0.0.0.9 (obviously invalid) or 250.204.72.95 (reserved IP space, not used), neither of which are valid IPv4 addresses.
in the database:
ActivityLog.IpAddress is varchar(200)
Customer.LastIpAddress is longtext
ForumPost.IPAddress is varchar(100)
Log.IpAddress is varchar(200)
Order.CustomerIp is longtext
I'm not sure if there are others, but considering these entities as example, i highly doubt any entities were made with an IP property specifically long enough for IPv4 (15 characters.)
The longest an IPv6 address can be is 39 characters. Or in the worst, highly unlikely, case IPv4 mapped to IPv6, it can be 45 characters long. So, even this shouldn't produce a problem for the given database entities.
I could see a change to this possibly making problems for plugins expecting an IPv4 address - but they should be compensating for that on their own if they require it.
The text was updated successfully, but these errors were encountered: