Problem/Motivation

IP Addresses are a common, standard "thing" displayed in the administrative UI that cannot be altered consistently.

Proposed resolution

Create an 'ip_address' element #type for renderable arrays. Even if the base element type only returns an un-altered string, this paves the way for hook_element_info_alter() to inject a #pre_render that should address most use-cases.

Remaining tasks

Patch.

User interface changes

None.

API changes

API addition of a new element type for IP Addresses.

Original report by @bertboerland

I would like to see a link from the statistics page from the Source IP address of the host that was logged to a configurable whois / online nslookup site. For example 145.222.1.2 towards ripe. Or maybe even beter -but with some OS depencies- using a local whois / nslookup client.

Comments

ricabrantes’s picture

Version: x.y.z » 7.x-dev

I think this feature are Interesting, any news??

kbahey’s picture

The feedback module already has code that does that, which we can steal.

It relies on prefixing the IP address with "whois.domaintools.com" and getting a lot of info on the IP address.

Dave Reid’s picture

Status: Active » Closed (won't fix)

This is outside the scope of core.

bertboerland’s picture

so blocking an IP address is fine to have in core, so any newbe admin will block google, but putting an a href around it isnt?

Dave Reid’s picture

Can you personally guarantee the service will always be available and never shut down for the life of the Drupal project? If not, we probably shouldn't link to it.

Dave Reid’s picture

Plus, if #381802: Have theme_username() show hostname for anonymous users if available lands we should be able to make a small contrib module that makes whos links for IP addresses when used as 'usernames', which is most of the cases in core.

bertboerland’s picture

No, *I* cant. but this the whois service, the reverse -so to speak- of dns on the internet. the net can work without the whois protocol.

But you are right, linking to an external source for 3 years that we dont control has its drawbacks

and I made another mistake, the delegation of ARIN to different whois servers is in the whois protocol if you use a good command line tool (the same as it is in the dns protocol with delegation) however, this works for the whois client, not for the weclient

So if we look for 145.222.1.1 in arin, we have to scrape the result https://ws.arin.net/whois/?queryinput=145.222.1.1 looking for ReferralServer: whois://whois.ripe.net:43 and then do a http://www.db.ripe.net/whois?form_type=simple&full_query_string=&searcht...

This is undoable and hence we should not add this option this way, unless someone knows a webservice that is the autority of the data (hence arin) that is complete or does redirect on http level toward the right service.

so, unless someone knows the solution without scaping, this feature requst can indeed be closed.

we might however put something in the help text about reverse looking up IP addresses to make sure what and who you are blocking

bertboerland’s picture

one additional remark though, instead of a whois, we could do a "Do you want these IP addresses to be reversed" (with better wording :-) and let the webserver perform a reverse lookup on the listed IP addresses. Or show the name wehn hovering over the address. Not enabled by default, since reverse lookups can be time consuming

drawbacks
1) this only works if the webserver is not behind a outbound firewall that blocks abound 53/udp
2) many ip addresses will not resolve
3) many names are not usefull for endusers/admins
4) 10.1.2.3 may reverse to host.example.com while not being part of example.com
5) as stated http://php.net/manual/en/function.gethostbyaddr.php is slow
6) we need to take special care for ipv6 addresses

but rething about this, it would be nice to hover over an ip address and have a "please wait" hovertip and then the reverse as well in the hoveripe

and /or, when you click "block 10.1.2.3" show the text "are you sure you want to ban 10.1.2.3 (foo.example.com)? [yes|no]"

this seems a better solution then a whois and is very doable I think by using a gethostbyaddr function

kbahey’s picture

Title: whois [IP] » Make IP address display themeable in the user interface, so we can tie in to whois, ...etc.
Status: Closed (won't fix) » Active

I am not hungup on tying this to a particular service, and yes, it is a concern if they are not there tomorrow or change their URL.

But we need a way to allow overriding the rendering of IP addresses, so we can hook into this or that service.

Perhaps a theme function is the best way here, and we can render the IP address any way we wish.

thedavidmeister’s picture

Title: Make IP address display themeable in the user interface, so we can tie in to whois, ...etc. » Make IP address display a render element type
Version: 7.x-dev » 8.x-dev
Component: statistics.module » markup
Priority: Minor » Normal
Issue summary: View changes

I'd suggest not a theme hook, due to performance considerations when rendering many IP addresses on one page. Maybe a render element type that could have a #pre_render attached?

'#type' => 'ip_address'

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.