Add IPv6 support for subscriptions

[asmecher]

IP-based subscriptions currently only support IPv4 addresses. Add support for IPv6.

[pmangahis]

+1 from PKP|PS journal

[Ian-BD]

Has there been any progress on this? I have a client who has users with only IPv6 addresses so support for this would be fantastic.

[asmecher]

No progress yet, I'm afraid -- subscriptions represent a relatively small portion of our user community, and IPv6 requirements rarer still. Here's what would be required:

• Adapt the institutional_subscription_ip database table schema to support longer IP addresses (for both mysql/mariadb and PostgreSQL -- unfortunately this will take some wrangling if there isn't a good option that'll work for both)
• Replace the use of PHP's ip2long function (e.g. here) with a binary representation of the IP range for storage in the database. At a glance, it just means being able to compare values to see if they are within a range.

[bozana]

Hi all, maybe above all @asmecher, I am wondering if I could consider this issue for 3.4, at least to consider the way we save the IPs in the DB. If it is to close to 3.4 release i.e. to late to make such changes, then maybe for the next release. I did a small research and there would be the PHP function inet_pton but I am not sure if we should use that PHP function or rather the DB functions. I am not sure how the result of the PHP function inet_pton would be saved in different DBs and how the query and comparison then happens. For example, if we would use Laravel Migration's ->binary it would create BLOB, which is probably not the best solution. And we will probably need to juggle with inet_pton and inet_ntop. Thus, I lean toward DB functions: For MySQL (MariaDB) the type would be VARBINARY(16) and we would use functions INET6_ATON and INET6_NTOA. PostgreSQL has network address types, so we would use inet. Else, we would proceed in the same way -- we would get start and end IP, and comparison would be using <= and >=, as till now. I would also add one more column that describes the family/version of the IP address (= 4 or 6), so that we query only the appropriate rows, depending on the user's IP (I assume there is a function to figure out if it is IPv4 or IPv6). Thus, the current DB table institution_ip would then be: | institution_ip_id | institution_id | ip_string | ip_start | ip_end | ip_version | ip_start and ip_end would be VARBINARY(16) i.e. inet. This would mean that we would have to differentiate between DBs, but... I would also need to find an algorithm that calculates start and end IP from an IPv6 range, but I hope I can find it :-)

EDIT: it seems to be too late for 3.4, but then for the next release...

[asmecher]

Hi @bozana! Yes, it's late for 3.4.0, unfortunately -- but we could opt to release a 3.4.1 and include database changes there if it's important to release this earlier than the 3.5.0 timeline.

[dmcconeghy]

We would also appreciate support for this feature as we have requests from multiple clients now.

[EquinoxSheffield]

Just checking if there is any progress on this issue and if so, when it is likely to be solved. Many thanks.

[asmecher]

@EquinoxSheffield, unfortunately there has not been development on this yet, nor is it yet scheduled for a specific release. Subscription-based publication is a relatively small element of our community and we've been busy with other priorities. Pull requests are welcome if someone is able to tackle the dev work. It's not particularly complicated, but will probably require a small database schema change, as noted above -- so wouldn't be possible to merge into our repos before 3.6. (If someone tackles this on an earlier release, it should be quite feasible to make local database mods to accommodate the changes prior to 3.6 coming out.)