| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is far better than pre-0.12, because we now have a universal way to
configure and enable/disable CORS on a per-module basis.
|
|
|
|
|
|
|
| |
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 might make the global routes less confusing sometimes, or at least
valid URLs instead of http://*:5280/ which doesn't make much sense.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
These would previously be left behind. Probably mostly harmless except
for clogging up the `debug:events()` listing in the console.
|
|
|
|
|
| |
Also special thanks to timeless, for wordlessly reminding me to check
for typos.
|
|
|
|
|
| |
Trying to move everything relating to proxies and X-Forwarded-Foo into a
single place.
|
|
|
|
|
|
|
|
| |
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?
|
|\ |
|
| |
| |
| |
| |
| | |
8603011e51fe optimized out more than just the loop, leaving the .ip
field blank when the request wasn't from a proxy.
|
| |
| |
| |
| |
| | |
is_trusted_proxy() is only in trunk, I dun goofed when I rebased
8603011e51fe from trunk.
|
| |
| |
| |
| |
| | |
This was the late night early draft text, thought I had amended this but
apparently I forgot.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Makes no sense to have a http module with no handlers
Would have helped me when I accidentally
module:provides("http", {
GET = handler;
})
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
E.g.
module:provides("http", {
cors = {
headers = {
Accept = true;
Expect = false;
};
};
route = { ... };
});
Case might be weird.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
E.g.
module:provides("http", {
cors = {
credentials = true;
};
route = { ... };
});
|
| |
| |
| |
| |
| | |
No need to do a subnet match comparison to see if two IP addresses match
exactly.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| |
| | |
Skips doing the whole get_ip_from_request() dance if the request isn't
from a proxy at all, even if the client sent the header for some reason.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #726
API:
module:provides("http", {
streaming_uploads = true;
route = {
PUT = function (event)
event.request.body_sink = io.tmpfile();
return true;
end
}
})
|
| |
| |
| |
| |
| |
| |
| | |
This enables uses such as saving uploaded files directly to a file on
disk or streaming parsing of payloads.
See #726
|
| | |
|
| | |
|
| |
| |
| |
| | |
Because docs are good.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
This allows disabling mod_http_errors by adding it to
moduless_disabled and ensures mod_http loads even if the error pages
aren't as pretty.
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Since it's mostly only mod_s2s that needs to request client
certificates it makes some sense to have mod_s2s ask for this, instead
of having eg mod_http ask to disable it.
|
| | |
|
| |
| |
| |
| |
| | |
Lower priority to allow http modules to handle it themselves, should
they wish to
|
|/
|
|
|
|
|
| |
This blindly allows any cross-site requests.
Future work should add an API to allow each HTTP app some influence over
this for each HTTP path
|
| |
|
|\ |
|
| |
| |
| |
| | |
(fixes #1183)
|
| |
| |
| |
| | |
Such modules simply ignore the Host header and always handle the same path.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Now an event like `GET /path` is fired at first, and mod\_http
dispatches the old `GET host/path` events.
|
| | |
|
| | |
|
| | |
|