Project:IP Login
Version:6.x-2.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:postponed

Issue Summary

Thanks for this module, and especially for the 2.x version.
I've some issues with it I'll try to solve (see #1271756: Wrong links to user account pages on subsites and #1271714: User ordering when multiple matches exists).

I needed subnet matching (see CIDR notation) in my project.
I've modified the ip_login_check() function to use ip2long. I think it allows better validation and matching.

Using the patch below you can specify the following address patterns:

  • Single IPv4 address
  • * wildcard, e.g. 192.168.100.*
  • IPv4 address range in the form of IP1 - IP2, e.g. 192.168.100.1 - 192.172.200.1
  • and finally, my favorite: IPv4 subnet in the form of 192.168.100.1/16

Patch file attached and needs to be reviewed.

AttachmentSizeStatusTest resultOperations
ip_login-ip_mask.patch6.92 KBIgnored: Check issue status.NoneNone

Comments

#1

Thanks for this.

Well, this is a huge change and will need careful thought... Not sure about the depth of this change or the mechanics until I have a change to test the code.

Will look at it when I have more time. Thanks again.

#2

Version:6.x-2.0-beta1» 6.x-2.x-dev

#3

Further to my comments on #1271714: User ordering when multiple matches exists, we need to ideally prepare for IPv6 stuff which will only get more pressing as time goes on -- AND improve database query matching speed - see: #1252994: ip_match should be a multiple value field, possible changes to schema for better performance.

I note the inet_ntop() function and its counterpart inet_pton() both look very handy...

#4

Status:needs review» postponed

Postponing major changes like this to the forthcoming 2.1 branch, want to get 2.0 out the way and bug-free first.

nobody click here