• last updated 15 hours ago
Constraints: committers
Constraints: files
Constraints: dates
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

Do not enforce that body is a list

Fix typo

Fix typo

Performance improvements:

- set variables from the ns_set and extended variables separately

- collect the values and append to the multirow in one sweep

- when no code body is there, just bulk append the values

This appears to be ~5% faster than db_multirow when both are invoked with a code body and ~30% faster when invoked without (with no prepared statements)

Simplify idiom

Fix behavior of continue in the multirow code block, make the generic fallback behave the same as the postgres version with respect to appending

Test ::xo::dc multirow further

- break and continue behavior in the code block (this will expose a bug)

- appending to an existing multirow

Cleanup leftover line

Extend automated tests to cover new ::xo::dc multirow api

Provide an ::xo::dc api to generate multirows

Notable differences with the classical db_multirow:

- a multirow will always be appended when it already exists. The constraint that the two multirows must have the same columns remains.

- no "if_no_rows_code_block"

- no unclobber

- no subst, do it yourself :-)

- no cache stuff

- support for prepared statements

The remaining behavior has been kept the same, e.g. variables will always be reset to empty string, even if they existed outside of the code block. Compatibility has been checked with knowns idiosyncrasies.

show the question_count in the title only while filling in the exam

use message key

    • -1
    • +1