Specify a local address when exposing ports with Docker

[gibson042]

cf. https://docs.docker.com/engine/reference/commandline/run/#publish-or-expose-port--p---expose

Notes: none

---

This PR currently has no changelog labels, so will not be included in changelogs.

A reviewer can add one of: T-Deprecation, T-Enhancement, T-Defect, T-Task to indicate what type of change this is, or add Type: [enhancement/defect/task] to the description and I'll add them for you.

[gibson042]

I'd also like to make a further change if you don't object:

Suggested change

	docker run -p 127.0.0.1:80:80 vectorim/element-web
	docker run --rm -p 127.0.0.1:80:80 vectorim/element-web

[germain-gg]

Before we can move this forward would you be able to write a description of what you're trying to achieve and what use cases you're trying to cater for

[gibson042]

This corrects what looks like accidental creation of potentially attackable network exposure. From the linked Docker documentation:

Note that ports which are not bound to the host (i.e., -p 80:80 instead of -p 127.0.0.1:80:80) will be accessible from the outside.

The local development server should instead be confined only to the local host unless there is specific reason to make it network available (which is what this PR addresses).

[novocaine]

The command is suggested to serve element-web as a web server, with all the use cases that entails.

I think you might be assuming that only a development or local use-case exists, but there is also the use case of serving it to other clients on the network (e.g. run your own app.element.io with your own customisations, as many people do).

[turt2live]

fwiw, the documentation in this area was written more as a point of interest rather than something to copy/paste. It's fairly rare that folks use bare docker commands these days, so the important aspect becomes the ports and container name.

[gibson042]

I think you might be assuming that only a development or local use-case exists, but there is also the use case of serving it to other clients on the network (e.g. run your own app.element.io with your own customisations, as many people do).

That use case is certainly valid, but I believe running a server that supports it should be intentional rather than accidental—it's generally bad form to encourage creation of unnecessary attack surface area.

fwiw, the documentation in this area was written more as a point of interest rather than something to copy/paste. It's fairly rare that folks use bare docker commands these days, so the important aspect becomes the ports and container name.

Acknowledged. Unless you see harm in these changes, though, I still consider it valuable to default to restricted access.

[novocaine]

I think you might be assuming that only a development or local use-case exists, but there is also the use case of serving it to other clients on the network (e.g. run your own app.element.io with your own customisations, as many people do).

That use case is certainly valid, but I believe running a server that supports it should be intentional rather than accidental—it's generally bad form to encourage creation of unnecessary attack surface area.

My suggestion is to list the different commands for the different use cases noting the implications.

[gibson042]

@novocaine Done.