Module talk:IPAddress

This module was considered for deletion on 2018 July 1. The result of the discussion was "keep".

Takes a single argument, a string, and returns:

• "6" if it is a valid IPV6 address
• "4" if it is a valid IPV6 address
• empty string if it is neither.

When applied to {{PAGENAME}}, this helps determine whether a template is being placed on an anonymous user page/user talk page or not, as used in Template:AfC talk:

{{#if:{{IsIPAddress|{{PAGENAME}}}}|I'm on an anonymous IP user or user talk page|I'm on some other page}}

Note that extra whitespace is not permitted (e.g. "127.0.0.1 " with an extra space at the end is not a valid IP address).

Returns 1 if the given argument is a valid IPv6 address, else 0.

Returns 1 if the given argument is a valid IPv4 address, else 0.

Is '00000000000005.10.10.10' a correct IPv4 address? --DixonD (talk) 07:53, 8 March 2013 (UTC)[reply]

good question. it's not so much about "more than 3 digits" as it's about leading zeroes: is 12.02.4.4 legal? how about 12.00.4.4? what are the rules?

current code allows those, as well as 1.00000000100.2.2, i.e, any number can be preceded by any number of 0's. it's relatively easy to disallow. from Dot-decimal notation#Caveat it can be concluded that preceding with 0's is not a good idea, and can lead to confusion- this may be interpreted sometimes to mean "octal". should i change the code to disallow? should we add it to the tests? peace - קיפודנחש (aka kipod) (talk) 09:06, 8 March 2013 (UTC)[reply]

Yes, I think it is better to disallow. I would change the regexp from "^(%d+)%.(%d+)%.(%d+)%.(%d+)$" to something like "^(%d{1,3})%.(%d{1,3})%.(%d{1,3})%.(%d{1,3})$". --DixonD (talk) 12:11, 8 March 2013 (UTC)[reply]

technically, what you suggest is not viable, because lua's string comparison is not real regex, and specifically, there's no support for quantifiers in curlies. It would also still allow 000 or 020 etc., which should also be disallowed. However, as i mentioned, the solution is not difficult. --קיפודנחש (aka kipod) (talk) 14:11, 8 March 2013 (UTC)[reply]

i did it the way i thought is right, i.e., disallow leading 0 (i.e., 0 is OK, but 02 or 00 is not). this cause one test to fail, for the string "00.00.00.00". not sure if this should fail (your answer above indicate you think it should), in which case we need to modify the test, or maybe it should pass, in which case we should modify the code. wither is easy. can someone point to an authoritative source that explains which of the following (if any) is legal?

00.00.00.00
000000012.13.14.15
012.13.14.15
01.02.03.04

if no authoritative source can be found, your opinion will be appreciated anyway. also, is there past behavior we should emulate, regardless of "what's right"? thanks. peace - קיפודנחש (aka kipod) (talk) 16:37, 8 March 2013 (UTC)[reply]

Ping in Ubuntu treats numbers starting with 0 as octal numbers. 012.13.14.15 is legal (actually in decimal: 10.13.14.15), but 08.8.8.8 is not valid (8 is not octal number). --Harriv (talk) 19:14, 16 March 2013 (UTC)[reply]

{{IP-user other}} had IPv4 and IPv6 detection using template code only, but Module:IPAddress does better detecting. So I made it so {{IP-user other}} now uses Module:IPAddress . So thanks for this nice module. (I am planning to use this stuff in some system messages later on.)

--David Göthberg (talk) 22:22, 27 December 2019 (UTC)[reply]

@KevinL: Per the discussion at my talk (permalink), I have added a function you can use to Module:IPAddress/sandbox. Once you're happy with it, it can be moved to Module:IPAddress. I guess that is the best place. This module is full-protected which might suit your purposes.

The function returns 'ip' if the input is an IPv4 or IPv6 address, or 'range' if a CIDR IPv4 or IPv6 range. Otherwise it returns an empty string. That should make it easy for testing with #if. Some examples of how to call it follow.

• {{#invoke:IPAddress/sandbox|isIpOrRange|1.2.3.4}} → ip
• {{#invoke:IPAddress/sandbox|isIpOrRange| 1.2.3.4 }} → ip
• {{#invoke:IPAddress/sandbox|isIpOrRange|1.2.3.0/24}} → range
• {{#invoke:IPAddress/sandbox|isIpOrRange|2606:6000:610A:9000:9DF6:CC8D:592B:1AE}} → ip
• {{#invoke:IPAddress/sandbox|isIpOrRange|2606:6000:610A:9000::/64}} → range
• {{#invoke:IPAddress/sandbox|isIpOrRange}} →
• {{#invoke:IPAddress/sandbox|isIpOrRange|}} →
• {{#invoke:IPAddress/sandbox|isIpOrRange|Jimbo}} →

The second example shows that leading/trailing whitespace is ignored. If some other way of calling it is wanted, or some change, let me know. I'm posting here to alert others watching this page. Johnuniq (talk) 09:20, 14 December 2020 (UTC)[reply]

@Johnuniq: This is perfect – thanks for your fast work here! Please go ahead and move this to the main module. I really appreciate it. Best, KevinL (aka L235 · t · c) 09:23, 14 December 2020 (UTC)[reply]

@KevinL: Hang on, you've got to test it first! Does it work wherever you're intending to use it? Johnuniq (talk) 09:27, 14 December 2020 (UTC)[reply]

Well, from the examples you wrote above, I'm suitably confident this will work . I know the code in Module:IP is well-tested and since this function relies on that I'm sure this will work too; I wasn't familiar with the lua syntax for testing the success of other functions, but I'm quite confident that you are! Based on the tests I've done on the beta cluster the parameter I'll be passing in is exactly in the form that your function accepts. Anyway, I'm quite confident that this works for me! Best, KevinL (aka L235 · t · c) 09:35, 14 December 2020 (UTC)[reply]

@KevinL: OK, it's not rocket science so I updated the main module. Johnuniq (talk) 09:55, 14 December 2020 (UTC)[reply]

I'm proposing to reuse Module:IP for all functions in this module. The change can be found at Module:IPAddress/sandbox. This would have the following practical effects:

• Accept ranges for all functions. This is my intended use case. There's nothing in the testcases about this, so I'm not sure if current users are relying on isIp/isIpV4/isIpV6 returning false for ranges.
• Generally more lax parsing, such as accepting leading and trailing spaces.

What do you think about this change? If it's something that will break other templates, then I would propose to add new functions to check if a string is an IPv4 or IPv6 IP or range. MarioGom (talk) 18:28, 18 March 2021 (UTC)[reply]

Probably desirable although I haven't looked at the details yet. It would be quite a lot more overhead but probably insignificant. Some thought about how Module:IPAddress is used would be good (if it's not used much, overhead doesn't matter). However, if it's going to be redone, please fix the atrocious global functions and fix any modules which use them. This is 2021 and global functions are known bad! For one thing, any module using Module:No globals will crash if it tries to use these functions. Johnuniq (talk) 00:58, 19 March 2021 (UTC)[reply]

I don't know how reliable it is, but according to "what links here", Module:IPAddress is not used by any modules (apart from itself for some weird reason). It is used by around 210 templates but I suspect that almost all of them are incorrect reporting by the tool, due to use of {{Userspace linking templates}} on the doc pages of those templates. There may be more, but the only templates I can find using this module are {{IsIPAddress}} and {{Xsign}}. The module is used at MediaWiki:Newarticletext. @L235: Did you use this module somewhere? Johnuniq (talk) 09:09, 19 March 2021 (UTC)[reply]

I currently use it in Mediawiki:Blockedtext but would be quite happy if this was merged into Module:IP! KevinL (aka L235 · t · c) 18:18, 19 March 2021 (UTC)[reply]

Ah, so Module:IPAddress is used at MediaWiki:Newarticletext and MediaWiki:Blockedtext. The proposal is not to merge the modules but to use Module:IP to implement the functions provided at Module:IPAddress while changing the documented behavior so, for example, 1.2.3.4/24 would be an "IP address". That would not affect the isIpOrRange function you are using. Johnuniq (talk) 00:01, 20 March 2021 (UTC)[reply]

Sounds good then! I have no permissions to edit this template, can any of you apply the changes in the sandbox? Is there anything that needs to be addressed before? MarioGom (talk) 16:44, 27 March 2021 (UTC)[reply]

The thing that's outstanding is fixing the globals as mentioned above. I'll have a look at that later. Johnuniq (talk) 00:50, 28 March 2021 (UTC)[reply]

I edited the sandbox to fix the globals. However I added a TODO note which is going to require quite a bit of thought because the changes (to accept ranges as noted above) might not be compatible with how this module is used. I'm not even sure if it is desirable: should 1.2.3.4/5 be regarded as a valid IPv4 address? Also, the testcases need thought. Johnuniq (talk) 08:38, 28 March 2021 (UTC)[reply]

My use case is distinguishing IPv4 address/CIDR from IPv6 address/CIDR (for {{Proxyip}}, {{Proxyip4}}, {{Proxyip6}}). I then use isIpOrRange or other methods to check if it's a range. My guess is that for any template or module using it for usernames it shouldn't make any difference. If you think the breakage risk is too high, then I would go for new functions like isIpV4AddressOrRange and isIpV6AddressOrRange. Although it can be simpler to keep it to 2 orthogonal aspects: IPv4 vs IPv6 and address vs range. MarioGom (talk) 14:30, 31 March 2021 (UTC)[reply]

(disclosure: i wrote this module years ago, i think per some request in wp:vpt or wp:lua): can one of you guys, in one of the next passes, also make the functions in this module "local"? it's a bit of a sticking point... peace - קיפודנחש (aka kipod) (talk) 17:39, 31 March 2021 (UTC)[reply]

I already cleaned the module and there are now no globals (in the sandbox). Some searching showed it is likely the globals are unused but we'll find out when the sandbox eventually goes live. I've been caught up off-wiki and haven't fully thought about the issue but new functions might be best. Johnuniq (talk) 03:03, 1 April 2021 (UTC)[reply]

Johnuniq: We have two pending issues. One is whether we want a separate set of functions or not. My guess is that current usages will probably be ok with the change, but I can separate the functionality if we want to be extra safe. The other is the question of strict/lax parsing. Module:IPAddress is quite strict while Module:IP accepts many addresses that are invalid (even if they can be parsed with some assumptions). I thought about proposing a bit of stricter parsing at Module:IP, like not accepting two zero compressions (::) in the same address. But I fear that following that road means it will never be done. MarioGom (talk) 17:18, 31 May 2021 (UTC)[reply]

It's two months since my last comment and that's too long for me to remember what this is all about. I edited Module:IPAddress to include my changes in Module:IPAddress/sandbox relating to style and to remove global functions. That will make a comparison easier.

• Module:IPAddress • Module:IPAddress/sandbox • different (diff)

isIpOrRange could be used to determine if given text (with the perhaps too lenient checking of Module:IP) is a valid IP or range. Then, if it contains / it's a range, and if it contains : it's IPv6. Johnuniq (talk) 05:09, 1 June 2021 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

p.isIpOrRange currently requires a frame and prevents other modules (which may not have the first argument as the string to check) from checking if a given string is an IP or range. Please change lines 46 to 59 with the following.

function p._isIpOrRange(s)
	local modip = require('Module:IP')
	local success, ip = pcall(modip.IPAddress.new, s)
	if success then
		return 'ip'
	end
	success, ip = pcall(modip.Subnet.new, s)
	if success then
		return 'range'
	end
	return ''
end

function p.isIpOrRange(frame)
	-- {{#invoke:IPAddress|isIpOrRange|x}} → 'ip' (IPv4/IPv6) or 'range' (CIDR IPv4/IPv6) or '' (invalid)
    return p._isIpOrRange(input(frame))
end

Chlod (say hi!) 17:43, 3 February 2022 (UTC)[reply]

This looks good, thanks. I updated Module:IPAddress/sandbox with a slightly tweaked version of the above (just a slight re-ordering to suit what is already in the module) and will do a final check a little later. Johnuniq (talk) 22:47, 3 February 2022 (UTC)[reply]

Done. Johnuniq (talk) 01:01, 4 February 2022 (UTC)[reply]

Thank you very much! Chlod (say hi!) 09:53, 4 February 2022 (UTC)[reply]

I've created the new functions isIpV4Range and isIpV6Range which do exactly what it sounds like. This is for use in Template:Vandal but can probably come in handy in other places as well. If noone objects in the next few days I will take the code in the sandbox live. There are testcases. --Trialpears (talk) 18:30, 10 January 2023 (UTC)[reply]

i do not see any such functions in the snadbox.

i am guessing the functions you describe reside somewhere else. furthermore, i am guessing they are in the same vein as _isIpOrRange().

presuming this is the case, i'll say what i should have said when this function was added: i think it's utterly silly. not the function itself, of course, but its inclusion in this module. i can't imagine what is the added value of placing in module A a function that does nothing but pipe calls to module B.

this practice makes sense when some of the "native" functions of A are using this implanted function, but this is not the case here, and _isIpOrRange, as well as the 2 new functions you describe are entirely for "export" purposes. all they do is pipe functionality of Module:IP, and my common sense says they should reside there. what is the value of planting this "foreign body" here?

tl;dr: please consider placing these new functions in module IP rather than here.

peace. קיפודנחש (aka kipod) (talk) 19:47, 10 January 2023 (UTC)[reply]

@קיפודנחש Here is a diff with the code at Module:IPAddress/sandbox and testcases at Module talk:IPAddress/testcases.

In principal I'm not opposed to having this in Module:IP instead, but if were going to have two separate modules, which the 2018 TfD thought was for the best, I feel this fits better here than in Module:IP since it's intended to be easy to use in templates while IP seems to have functions primarily intended for use in Modules. --Trialpears (talk) 20:22, 10 January 2023 (UTC)[reply]

thanks. don't know how i missed them earlier. i have some excuses, but i doubt anyone here will be interested.

those functions seem to be in the right place - they do use the functionality of this module, and do belong here, contrary to my previous assumption they do not, which was made before reading the code. thanks.

btw, the addition of these functions (retroactively) justifies the inclusion of _isIpOrRange() here...

will be good to add testcases, both positive and negative, before merging the sandbox to the module itself.

peace. קיפודנחש (aka kipod) (talk) 00:10, 11 January 2023 (UTC)[reply]

This edit request has been answered. Set the |answered= parameter to no to reactivate your request.

Please implement my changes in Module:IPAddress/sandbox.

This adds some logic to detect temporary and permanent accounts in addition to IP addresses, which can help to display certain system messages based on the kind of user. Aasim (話す（はなす）) 02:29, 8 December 2025 (UTC)[reply]

That code seems to me like it would belong in a separate Module:Temporary accounts, not in this one, since it has little to do with IP addresses. * Pppery * _{it has begun...} 00:23, 11 December 2025 (UTC)[reply]

agree with pppery. קיפודנחש (aka kipod) (talk) 13:35, 11 December 2025 (UTC)[reply]