When a user enters a search term that is too generic, slcl would
generate a long list of search results, where this generation could have
a big impact on the server performance and its available resources.
Therefore, it is reasonable to limit the number of search results to an
arbitrary limit, so that users are forced to enter a more specific
search term in order to achieve more relevant results.
So far, cftw would search through all directories and files recursively,
until all objects are processed. However, it is interesting for the user
callback to be able to stop this process under specific circumstances.
Now, cftw will pass a pointer to a bool, initialised to false by
default, that can be optionally assigned to true by the user
callback.
Future commits will make use of this feature. For example, this will be
used to limit the number of search results when a user enters a search
term that is too generic and would otherwise generate a large amount of
search results.
slcl used to provide a hardcoded stylesheet. However, it would be
desirable for some admins to provide a custom stylesheet without having
to rebuild the application.
Now, slcl creates a default stylesheet, namely style.css, into the
target directory, that can be later modified by admins.
While this might contradict the suckless philosophy a bit, hopefully
some admins might find this new feature useful.
- The back button would not return to the previous directory, but to the
user root directory.
- While this could have been solved easily (e.g.: by inserting the
referrer directory into the form), it would have implied extra and
unneeded complexity.
When the distance between '*' on a wildcard expression was larger than
the string to compare with, this would cause an out-of-bounds read
because `n` was not being limited to the strlen(3) from the input
string.
Example:
- s="c", p="*cc*", casecmp=false
Here, the distance between the first and second '*' is 2 bytes, which is
longer than the input string itself (1 byte, not counting the
terminating null byte '\0').
- Relative paths must not be used for filenames or directory names,
such as "..", "." or "dir/..".
- Paths with asterisks ('*') must not be allowed, to avoid confusion
with wildcard expressions.
- '.' or '..' must not be used for filenames.
- Filenames must not contain forward slashes ('/').
- Filenames must not contain asterisks ('*') to avoid confusion with
wildcard expressions.
The following workflow has been implemented:
- A new checkbox for each object inside a directory is shown.
- When one or more objects are selected, the user submits a request
through a HTML5 form.
- Then, slcl will ask the user for confirmation, listing the selected
objects, while reminding the user about the effects.
- The user confirms the selection.
- slcl removes the selected objects. All objects from non-empty
directories are removed, too.
- Finally, slcl redirects the user to the directory the request was
made from.
This provides a few benefits:
- This will allow searching for directories by name.
- Future commits will allow to remove files and directories, so this
change was also required for cftw.
When search_fn fails, it must free `r` before `results`, as the former
is assigned based on the latter - otherwise, it would lead to undefined
behaviour.
So far, only memory allocation errors would make search_fn to fail.
According to POSIX.1-2017, applications are advised to assign errno(3)
to 0 before a call to readdir(3), and compare errno(3) after the call to
check for errors.
C99 §5.1.2.2.1 only defines the following declarations for main:
- int main(void)
- int main(int argc, char *argv[])
While the use of equivalent types (e.g.: char **argv) is allowed, const
char ** would not be considered equivalent, and thus an invalid
declaration depending on the implementation.
server.c kept an array of all of its active clients, calling realloc(3)
everytime its size had to be modified. However, reallocating this array
had the undesired consequence of moving other active clients to other
memory locations.
Potentially, this would result in dangling pointers from other
components that also kept pointers to struct server_client instances
e.g.: handler.c.
For this reason, the array-based approach has been completely dropped,
in favour of a doubly-linked list.
This new feature adds a HTML form on each directory listing that allows
to search files recursively, starting from the current user directory.
Wildcard patterns are also allowed.
Otherwise, this would generate strings such as "directory//resource" if
dirpath contained a trailing slash, which could be problematic for users
relying on ctfw.
While commit 1ffba8f5 fixed a wrong display of the mkdir, upload and
logout forms, it did not take login forms into consideration, which must
displayed as grid.
Under some circumstances, clients could cause SIGPIPE to slcl. Since
this signal was not handled by server.c (i.e., via sigaction(3)), slcl
would crash without any error messages printed to stderr.
In such situation, SIGPIPE should not be usually considered a fatal
error, so it is preferrable to close the connection and keep working.
Given the following contrived example request:
/example%FB%DC&arg%DE1=examplevalue%AA
slcl must decode each token separately, so that percent-encoded
characters '&', '=' or '?' do not get accidently intepreted.
Due to the lack of double quotes, passwords with whitespaces were not
passed correctly to printf(1), thus making users not able to log into
their account.
OTOH, for some reason usernames containing whitespaces made jq(1)
complain, so it has been decided not to support them.
Otherwise, write_body_mem and write_body_mem would silently fail,
causing undefined behaviour.
Notes:
The return value for write_ctx_free is currently assigned to that of
fclose(3), which can be either 0 on success or EOF on failure.
However, it makes sense for write_body_mem and write_body_mem to simply
check against non-zero.
Also, it would not be sensible to return EOF to caller functions, which
expect either 0 (success), -1 (fatal error) or 1 (input error).
Considering http.h defined HTTP/1.1-only responses such as "303 See
Other", as well as incoming HTTP/1.1-only features (e.g.: byte serving),
it did not make much sense to keep a somewhat broken compatibility
against HTTP/1.0.
Unfortunately, this breaks support with some existing clients such
as lynx(1), even if HTTP/1.0 was already deprecated many years ago.
However, even lynx(1) can be configured to support HTTP/1.1.
select(2) has a number of well-known issues (e.g.: FD_SETSIZE limiting
the maximum amount of file descriptors to watch) that are mostly solved
by poll(2) and thus can be used as a drop-in replacement.
When using HTTP "Content-Disposition: attachment;", users are forced to
download files in order to use them, whereas others might prefer to open
them in the browser.
Therefore, now that URL parameters are supported by http.h, previews can
be forced by adding "preview=1" or "preview=true" (case-insensitive) as
a URL parameters. Any other parameters are ignored by slcl.
For users, a "Preview" link has been added next to the "Share" button
for each file.
Now, http_payload includes a list of human-readable parameters that can
be read (but not modified) by users. Given the following example link:
/test?key1=value1&key2=value2
This will generate two parameters, with the following values:
{
.args =
{
[0] = {.key = "key1", .value = "value1"},
[1] = {.key = "key2", .value = "value2"}
},
.n_args = 2
}
As expected, if any URL parameters are given, struct http_payload member
"resource" is accordingly trimmed so as not to include any parameters.
Therefore, considering the example above:
{.args = {...}, .resource = "/test"}
Limitations:
- Since the definition of struct http_arg is both shared by http.h
(as a read-only pointer within struct http_payload) and http.c
(as a read/write pointer within struct ctx), its members (namely key
and value) must remain as read/write pointers, even if they must not
be modified by users of http.h.
