Unexpected interaction between --disable-socket and --allow-hosts about pytest-socket

[sloria]

adding the --disable-socket would be unnecessary.

True, but it's un-intuitive for --disable-socket to take precedence over --allow-hosts when both are passed. Either allow users to pass both and fix the behavior or disallow passing both (i.e. raise an error).

[joetsoi]

https://github.com/urllib3/urllib3/blob/main/src/urllib3/util/connection.py#L63-L72

So I've bumped into this due to the way socket is used in urllib3, socket.socket is called before socket.socket.connect. Causing a SocketBlockedError() to be raised before the guarded connect is called.

Current behaviour disable_socket does not reset the guard, but it just blocks at an earlier point. (i.e SocketBlockedError is raised instead of SocketConnectBlockedError)

Why would I want to do this? Because I want to --disable-socket globally and then allow hosts for a specific test, so best way to allow that is to mark with both allowed_hosts and enable_socket

        @pytest.mark.allowed_hosts("localhost")
        @pytest.mark.enable_socket
        def test_something():
            ...

It sounds like erroring when both --allowed-hosts and --disable-socket are provided might be sensible, and maybe add something to the docs with the above example if you want to enable for specific tests?

[miketheman]

Hey gang! Thanks for your patience - I've worked out the precedence levels, and have pushed the latest code the the main branch. I'll aim to cut a release sometime within the next couple of weeks, keep an eye out for that!

[sloria]

Alternatively, an error could be raised if both arguments are passed.

I don't have a strong preference for (1) allowing --allow-hosts to take precedence or (2) raise an error. Both are better than the status quo, IMO.

[miketheman]

I wonder if that has to do with the approach of closest marker, from here:

pytest-socket/pytest_socket.py

Line 90 in 4c2bd57

mark_restrictions = item.get_closest_marker('allow_hosts')

It also looks like there's not the test case you're specifying - but I feel like the --allow-hosts ought to disable anything other than the allowed hosts, so adding the --disable-socket would be unnecessary.

[SHxKM]

@sloria - did you find an elegant way to deal with?

[atugushev]

I believe this is because disable_socket resets the guard set by socket_allow_hosts, see:

pytest-socket/pytest_socket.py

Lines 68 to 75 in 262513b

	def disable_socket():
	""" disable socket.socket to disable the Internet. useful in testing.
	"""
	def guarded(*args, **kwargs):
	raise SocketBlockedError()
	socket.socket = guarded

UPDATE: and also there must be socket.socket.connect = guarded

[miketheman]

Version 0.3.5 was just released with a slight modification to the ordering behavior of disable-socket and how it might impact the allow-hosts approach.

Can someone who's been impacted by this re-test, and if it's still not working, provide reproducible example? Some good guidance here: https://stackoverflow.com/help/minimal-reproducible-example

[ryanjdillon]

I just ran into this, as I'm using motoserver to mock AWS services, so I want to allow connections to localhost, and block to AWS.

I also assumed that --disable-socket --allow-hosts=127.0.01,localhost would do what I wanted. I only discovered this behavior by looking through the issues here.

[miketheman]

Thanks for the input everyone - I think I have enough details to establish what's wrong.

TL,DR: there's a logical conflict between the config options, leading to failed outcomes. This is likely to change the
flag combinations, so I'm treading carefully.