I am using Pelican to set-up a blog. Upon starting up the dev server, I get a warning:
Do you want the application “Python.app” to accept incoming network connections? Clicking Deny may limit the application’s behavior. This setting can be changed in the Firewall pane of Security & Privacy preferences.
I am sure I've seen this warning before (Django?), and just absentmindedly accepted it. I have been trying to figure out what it actually means, though, which sent me down the rabbit hole of network programming.
I have figured out that Pelican defaults to binding its server socket using INADDR_ANY, which led me to a couple questions:
- Is there any benefit to binding with INADDR_ANY rather than INADDR_LOOPBACK?
- The standard way to connect to the dev server is localhost:8000. Are there cases where one wouldn't just use localhost?
- Is there any risk associated with using INADDR_ANY?
- I presume there is some risk or other associated with using INADDR_ANY, or the warning wouldn't pop up. My guess is that someone could theoretically send HTTP requests to my socket and mess with, well, whatever my HTTP handler would let them?
I would appreciate if any answers provided basic definitions of network programming terms / concepts if reasonable. My knowledge of the subject is limited to a weekend's study.
UPDATE
Remy's answer is concise and seems spot on. But, while it explains the concepts, it does not directly address a few of my questions. I'll expound a little in case anyone else sees this:
Binding to INADDR_ANY (0.0.0.0) I discovered is also the default for Python's http.server. Apparently this leads to fewer complaints from people who don't know a thing about networking (e.g. me), per the main Pylons contributor. Things such as virtual machines are mentioned as progenitors of frustration.
The only immediate risk with binding to INADDR_ANY is that someone else on your local network could potentially connect to your dev server. But as long as you don't share internet access with your sworn nemesis, you're perfectly fine. The only risk from external sources (beyond your local network) would come if you explicitly allowed it via setting up appropriate port forwarding.