| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Supporting both methods at the same time may open to spoofing attacks,
whereby a client sends a Forwarded header that is not stripped by a
reverse proxy, leading Prosody to use that instead of the X-Forwarded-*
headers actually sent by the proxy.
By only supporting one at a time, it can be configured to match what the
proxy uses.
Disabled by default since implementations are sparse and X-Forwarded-*
are everywhere.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Prefer over X-Forwarded-* since it has an actual specification.
Main practical difference is that Forwarded may carry more properties
than only the IP address since it is a structured header.
Since we parse it into an array, it is easier to do the logical thing
and iterate backwards trough proxies until an untrusted one is
encountered. Compare the handling of X-Forwarded-For.
The 'secure' field now accounts for the full chain of proxies, which
must be secure all the way to be considered secure.
|
|
|
|
|
|
| |
There are hints that this format might be used in X-Forwarded-For as
well, so best handle it everywhere. Strips both brackets and optional
port number.
|
|
|
|
|
|
|
|
| |
This could be of help when configuring reverse proxies, as it is the
internal URL the proxy must point at.
Argument treated as an enum "internal" "external"(default) to allow for
future extensibility.
|
|
|
|
|
|
|
|
| |
a863e4237b91 unintentionally changed the format of HTTP CORS headers,
which were apparently relying on the output of tostring(), which it
shouldn't have.
Explicitly serializing it this time.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|