The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Next to setting the IP-address of a user to enable automatic login, I need to restrict the access of users based upon the IP-adress. This functionality is also provided by modules like listed below. Would this functionality fit in IP_Login?
- http://drupal.org/project/restrict_by_ip
Maintenance status: Actively maintained
Development status: Under active development
Reported installs: 190 sites (only D6).
Last modified: June 23, 2011
- http://drupal.org/project/restrict_ip
Maintenance status: Actively maintained
Development status: Under active development
Reported installs: 50 sites (40x D6 + 10xD7 )
Last modified: January 11, 2011
Comments
Comment #1
jim kirkpatrick commentedIt certainly would. But then it's a departure from IP Login's core focus, so I'm wary of stepping away from the 'keep it simple, stupid' approach.
But the fact remains that the guts of the IP matching and user account relationship is needed by all these modules, and probably more. This implies that perhaps we need a new 'IP Tools API' module than can do the heavy lifting of these modules, thus turning IP Login, Restrict and others into simpler modules that can focus on great UI and behaviour without re-inventing the wheel.
Then there's a bunch of modules in the same realm, http://drupal.org/project/geoip for example
I see that restrict_by_ip has this #721684: Not IPv6 compatible and indeed a patch towards IPv6 compatibility. We need that too!
Bottom line: IP Login does what it does very well and is - barring a few minor feature requests and as-yet-unneeded IPv6 compatibility - is complete. It appears the same is true of these other modules. However, they all share a core of IP range/subnet/wildcard matching, prioritisation, comparison and finally connection to entities like Users or other actions... This seems to me to be a potentially very rich opportunity to share code, features and support.
I'm going to ask some other module maintainers to chip in, but in the mean time, what do you think?
Comment #2
johnvIndeed, splitting the IP-engine from the UI seems a good idea. Perhaps we could check out http://drupal.org/project/logintoboggan, which hosts a myriad of options.
What steps would be necessary?
- admin UI: one or more tables to host IP-adress + uid + action_code
possibly 1 table is sufficient, until proven otherwise. We'v already been discussing a mutli-value field, so each row may have its own action.
- hook_boot(); find the matching records; loop over matched records and execute action.
this means implementing callback functions, depending on the action_code, and setting a weight on each action (you first want to check the valid IP-address, then an automatic login from this validated IP-address)
Splitting the current module in separate files seems better for keeping an overview:
- The admin functions go into a separate file 'admin.ip_login.inc'.
- Some functions go into a separate file 'automatic.ip_login.module' (hook_permissions, hook_form_alter)
- The API-functions stay in ip_login.module
I'm not sure if the module should be hot-pluggable, so each submodule may be implemented independently. Haven't checked the layout of the other modules yet.
Comment #3
jim kirkpatrick commentedGood thinking... Let's not forget Rules too -- an IP engine providing actions/triggers to Rules for further processing would be very powerful and pretty cool.
The actual architecture needs some careful thought, and should leverage existing PHP IP frameworks if they exist... My brain's fried today, will come back here soon.
Comment #4
jim kirkpatrick commentedI contacted james_g, who's done a few IP type modules and he thinks the idea is a good one:
So we have some interested parties, including Peterx over here: #1252994: ip_match should be a multiple value field, possible changes to schema for better performance, JohnV and others... Interesting.
Comment #5
peterx commentedI modified IP login for a few things that might fit an API.
* IP Login now adds an IP Login role to every user. If a user is already logged in, IP Login still checks the IP address and assigns the standard role. There could be an admin selection list for the standard roles.
* IP Login now merges roles. If a user is logged based on IP then logs out and logs in with their own user ID, they get both sets of roles. They get their own roles, they get the standard role from IP Login, plus all the roles assigned to the user attached to the IP address. The extra roles are stored in the session along with the IP Login result.
* On one site the users are moving between two networks from different carriers with different IP addresses. They have the same continuous session but change IP address occasionally. This occurs with people using a netbook on a local network then switching to wireless when roaming. It might be worthwhile caching multiple IP addresses in the session or providing a config option to allow the change of IP address. In other situations, a change of IP address would indicate a security problem.
Comment #6
johnvJust for inspiration: #1161486: Move IP blocking into its own module , which adresses core functionality: admin/config/people/ip-blocking
Comment #7
jim kirkpatrick commentedI'm going to merge this and other issues in to a new ticket that handles the outstanding schema/db changes and paves the way for the future... more soon.
Comment #8
johnvonly for referencing. Apart form other functionality, they offer alternative storage methods. If storing IP's as longs are faster to compute (and if this improvemnt is significant) , 'our' table as mentioned in #2 would look like:
IP-adress_from + IP-adress_to + uid + action_code
http://drupal.org/project/field_ipaddress
(addresses are stored as a long which allows you to compute quickly (e.g. is 10.10.10.10 within the range 10.10.10.0 - 10.10.10.50).)
http://drupal.org/project/ip_ranges
IP-address can be either single IP ( e.g. 100.100.100.100) or range (e.g. 100.100.100.100-100.100.100.150)
Comment #9
johnvOnly for referencing:
I found this module, which looks like a collection of IP-adresses, with actions attached. Perhaps, IP-login could be such an action:
http://drupal.org/project/ip
Comment #10
davidwhthomas commentedIP Login isn't about username / password login validation and thereby restricting users to a particular IP address.
It's about allowing a user to login without entering username / password.
So in that sense, I don't think that's in scope for this module.
That existing module http://drupal.org/project/restrict_by_ip looks like it already provides that feature.
As for http://drupal.org/project/restrict_ip I'm of the opinion that stuff is better done in the server configuration, e.g virtual host conf or .htaccess with allow / deny rules, rather than drupal.
DT
Comment #11
amateescu commentedThere's also https://www.drupal.org/project/restrict_login_ip now, and I agree with @davidwhthomas that it's not really in the scope of this module.