Behavior change: It becomes up to the authorization module whether to
allow requests. The default, mod_authz_internal, will allow users on the
*parent* host only, breaking use by some components.
Remaining question is whether to deprecate the `http_file_share_access`
setting or leave as a way to complement/bypass access control?
Many of these fall into a few categories:
- util.cache size, must be >= 1
- byte or item counts that logically can't be negative
- port numbers that should be in 1..0xffff
Removed in 536055476912 because it was not used anywhere else in the
file, but per the documentation it is meant to inform external upload
services of the expiry time of the upload itself.
Overrides the util.jwt default of 1h with the intended TTL of 10
minutes. Because util.jwt now has its own expiry checks, so the 'expiry'
field is no longer used and can thus be removed.
Updated by Zash, the original patch by Jonas had put the duration
parsing function in util.datetime but MattJ later did the same thing but
differently in f4d7fe919969
Some changes/improvements in this commit:
- Default token lifetime is now 3600s (from 300s)
- Tokens are only validated once per upload
- "iat"/"exp" are handled automatically by util.jwt
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.
The Lua string.format %q doesn't behave correctly for all characters
that should be escaped in a quoted-string. And who knows what effects
higher Unicode might have here.
Applying percent-encoding of filenames seems like the safest way to deal
with filenames, as well as being easier than implementing the actual
quoted-string transform, which seems complicated and I'm not even sure
it covers every possible character.
Filenames can safely be assumed to be UTF-8 since they are passed in an
attribute in the query without any escaping.
Metrics available or not depending on configuration is weird, even tho
it might be expensive to calculate and it's only really needed when
there is a global quota.
Default quota is set to infinity, which is essentially what it was.
Reports NaN if there is an error, which should count as over the
infinite default quota.
Before mod_cron this job ran less frequently than the upload removal
job. Running them at the same frequency seems wasteful somehow, plus the
total should not drift away from the true value that fast.
Not sure what the benefit of two separate loops was, perhaps reduced
memory usage by allowing archive query state to be garbage collected
before moving on to deleting files. Never measured so probably not so.
This simplifies a bit.
This is probably a bad idea, as files that could not be deleted for some
reason will not be tried again. I was just thinking of what the 'task'
argument could be used for.
If the request fails in the middle then the file~ could be left behind
because no code was invoked to delete it then. This gets rid of it when
the request is removed. It may still be left in case of an unclean
shutdown.
Can't find anything saying anything on whether this is needed or not.
kawaii reported that both Chrome and Firefox complained unless the
header was added to the list of allowed headers.
Before, maximum storage usage (assuming all users upload as much as they
could) would depend on the quota, retention period and number of users.
Since number of users can vary, this makes it hard to know how much
storage will be needed.
Adding a limit to the total overall storage use solves this, making it
simple to set it to some number based on what storage is actually
available.
Summary job run less often than the prune job since it touches the
entire archive; and started before the prune job since it's needed
before the first upload.
X-Frame-Options was replaced by the Content-Security-Policy
'frame-ancestors' directive, but Internet Explorer does not support that
part of CSP.
Since it's just one line it doesn't hurt to keep until some future
spring cleaning event :)
Only a starting point is supported due to the way response:send_file()
sends everything it gets from the provided file handle but does not have
any way to specify how much to read.
This matches what Conversations appears to be doing.
Lets an external upload service know this so it can do expiry itself.
Could possibly have been calculated based on the token expiry or
issuance time, explicit > implicit.
