• last updated 10 hours ago
Constraints: committers
Constraints: files
Constraints: dates
Reinstate lost comment

Use modern date and time form input types so that the time values validated by the contract are the same used by the UI and no different values can be supplied to the form via the pseudo-fields for e.g. year, day and so on...

    • -81
    • +27
Improve validation

Cleanup leftover, fix typos

lc_time_tz_convert reform:

- enforce that only dates in the ISO format "%Y-%m-%d %H:%M:%S" are accepted

- apply clock api normalization to seemingly out of range time_values, as per https://www.tcl.tk/man/tcl/TclCmd/clock.html#M25

- return the empty string every time input is invalid or a conversion cannot be determined

- return a value, as ISO date, only when conversion is successful

- prefer the clock api to perform the conversion, but fall back to the ref-timezones datamodel when the timezone is not supported by Tcl

Introduce a thorough test of the lc_time_tz_convert api checking:

- dates in the distant past

- dates in the distant future

- daylight saving for different times of the year across the two timezones

- historical circumstances (e.g. Pre-timezones US)

- Invalid input

The test shows that the current api does not behave consistently in certain circumstances:

- the same time_value is sometimes returned with invalid input

- the empty string is sometimes returned with valid input

- for dates where the ref-timezones package does not provide information, no result is returned

Performance improvements:

- add with_headers flag to ::xo::dc list_of_lists behaving like the db_list_of_lists counterpart

- use ::xo::dc list_of_lists as internal for ::xo::dc foreach and ::xo::dc multirow to reduce the need for ns_sets

Collect all query results before executing the code to avoid the out-of-pools bug

Implement a test making sure ::xo::dc "loop code-executing" api is not subject to the "out of pools" bug

-prepare flag must not be supplied when not available

Fix regression: the reimplementation of ::xo::dc foreach reintroduced the old "out of pools bug"

The fix makes again use of the ns_set api to free the handle before the code is executed

set return_url via ::xo::cc to avoid "connection socket is detached" error

Adding one more safety belt for potential DOS attacks

For cases, where request blocking is activated (returning 429 status

code for repeated requests), one more check was added: When such a

block happens more than 15 times in a minute on the same URL from the

same user, more requests for the same URL and user will be blocked

until the minute is over. The user seese the message "This web server

is only open for interactive usage".

Background: While request blocking works well for interactive users,

it might not be sufficient for web clients running wild. Normally,

after a 429, the user can reload the page to receive the content of a

page. This leads to a sequence of requests of interleaved 200 and 429

status codes, which might be ignored by a bot (or ad DOS attack). When

the requested page is slow, this can bring a server to its knees.

When request blocking is deactivated, this change has no effect.

Do not abort after the redirect, or the rest of the workflow logic after this action won't fire

Fixes xowf.create_test_items automated test

Test issuing the action "logout" to submit an inclass-exam, both with and without a return_url

Shorten idiom

Modernize and tighten page contract

Protect against malicious inputs, where the value won't be a list

Remove hack and prefer to document limitation in the automated test

Fix typo and include again the hack for strings with colon char in the fallback implementation of ns_pg_prepare

Fixes xotcl-core.test_prepared_statements automated test

document public api question_statistics_block

improved spelling

use the built-in bindvars parser (when available) for prepared statements

harden policy

Handle the case of user misconfiguration, where no item type is selected for a pool question: the resulting filter clause would be invalid in this case

split up question_info_block method

Update api

Do not extend the existing multirow, we only enforce that this call will have the same columns

Test that appending to an existing multirow from the db works as expected: when the columns defined via query and extend are the same, this should succeed

Don't collide with multirows created by other tests