Because it changes the type of the 'opt_origins' variable from util.set
to the internal _items table so next time an http app is added an error
"attempt to call a nil value (method 'empty')" is triggered. The value
is not used anywhere else.
Noticed when reviewing uses of the '_items' set property.
Not reported by any users, implying this setting is rarely used.
Fixes#1779.
Due to an oversight in the logic, if the user set 'enabled' to false in an
override, it would disable the item's requested CORS settings, but still apply
Prosody's default CORS policy.
This change ensures that 'enabled = false' will now disable CORS entirely for
the requested item.
Due to the new structure of the code, it was necessary to have a flag to say
whether CORS is to be applied at all. Rather than hard-coding 'true' here, I
chose to add a new option: 'http_default_cors_enabled'. This is a boolean that
allows the operator to disable Prosody's default CORS policy entirely (the one
that is used when a module or config does not override it). This makes it
easier to disable CORS and then selectively enable it only on services you
want it on.
The same-origin policy enforced by browsers is a security measure that should
only be turned off when it is safe to do so. It is safe to do so in Prosody's
default modules, but people may load third-party modules that are unsafe.
Therefore we have flipped the default, so that modules must explicitly opt in
to having CORS headers added on their requests.
http://[::]:5280/ is as sensible as http://*:5280/ so why not
This might be a bit weird when listening no multiple interfaces but not
sure we can really do anything sensible then anyway.
This is either caused by an earlier failure to bind http/s ports, in
which case that should be corrected, or explicitly disbling the http/s
ports, in which case ... why enable http modules?
Suggested by jonas’
When http_external_url is set then the portmanager usage only really
serves as a check of whether any http service is enabled at all.
Should allow generating an URL from prosodyctl when http_external_url is
set.
Since accessing this port directly over the wider Internet is unlikely
to intentional anymore. Most uses will likely be by reverse proxies, by
mistake or because of trouble configuring HTTPS.
Blocking mistaken uses is just a good thing, letting users send
potentially private things unencrypted tends to be Strongly Discouraged
these days.
Many reverse proxy setups operate over loopback, so listening there
instead of all interfaces is a net improvement.
Improved automatic certificate location and SNI support has mostly
eliminated the need for manual certificate configuration so HTTPS should
Just Work once certificates have been provided.
For local testing during development, connecting over loopback is likely
fine as well. When really needed, `http_interfaces` can still be set.
Suggested by Link Mauve
Because it already sets request.secure, which depends on the connection,
just like the IP, so it makes sense to do both in the same place.
Dealing with proxies can be left to mod_http for now, but maybe it could
move into some util some day?
Should be better than setting consider_{bosh,websocket}_secure as that
may end up causing actually insecure requests to be considered secure.
Doing it here, as with IP, should make this apply to all HTTP modules.
Potentially a bit more efficient since it can jump to the selected
protocol on connect instead of waiting for some data to look at.
Adds a 'protocol' field to net providers for this purpose.
These are similar to the "activated service" messages from portmanager
and similarily useful for the service admin to know even if they're not
debugging anything.
Prevents CORS related handlers from being left over on reload.
BC: `mod_http.apps[app_name][event_name]` is now a table instead of the
main handler function.
