CourseForge 5.2.0

Publishing is a task, not a request. Pressing Publish writes a task down
and returns; the scheduler works it in slices of one tick each, and the tab can
be closed. A push interrupted half way - a wiki that stopped answering, a host
time limit, a process that died - is picked up again from the page it stopped
at, never from the start, with a growing pause between attempts and a ceiling
you can set. One wiki failing does not stop the others, and only the failed one
is tried again. On an installation with no scheduler the browser works a queued
task itself, one bounded slice per request, and says so.

The publish log lives on the server. Every line a task says is written down
as it is said, with the wiki it belongs to, and shown whenever the tab is
opened - including the pushes that ran while nobody was looking. Stop and Retry
are yours; Retry carries on from where the task got to.

Each destination has its own card. The book, the shelf, pages published,
out of sync, never published, how the cross references resolve, and the last
outcome - per wiki, beside a card that speaks for all of them. Publish here,
Book only and Resolve links here act on one wiki.

Several invites at once. An invite carries a label - who it is for - and
any number may be open together. A code issued from the app is shown exactly
once and written to no file; only the first-run invite still goes into
INVITE-CODE.txt. Revoke one and the others stand.

A guided tour. It starts by itself the first time an account signs in and
walks through every screen and every setting, spotlighting each section as it
explains it. An administrator and a user get different tours. Cancel it at any
time; open it again from the button above the theme switch.

Administration › Security. CourseForge asks the server for its own private
files over HTTP and reports which came back - the data directory, the
database, the deny file, the configuration. Until every one is refused, every
field that would store a secret is locked and carries a red mark that leads to
the screen; the screen names the server it detected and gives the configuration
block for it, and the one arrangement that is safe everywhere. An administrator
who has verified the server by hand can accept the risk by typing a code shown
on the screen, which is recorded with their name.

A security review, applied. Addresses a profile carries are vetted before
they are called and never have their answers quoted back; the shared cURL
wrapper speaks HTTP only; a blank secret is carried forward only for the address
it was stored against; Host is used only when it looks like a host and
X-Forwarded-Host never; sessions use strict mode and are renewed on a password
change; password changes are throttled like sign-ins, in the browser and over
MCP; an account lock no longer shuts out the address the owner signs in from;
request bodies are capped; connection tokens minted over MCP die with the
connection that minted them and never carry a scope the account lacks; the MCP
origin check measures against the configured address; tool results are cut at
the size the tool declared; a look may load its libraries only from the module
CDNs or the installation itself; the BookStackDev endpoint varies its cache on
the header that decided, answers preflights only for allowed origins, and no
longer names the look in a refusal; embeds run sandboxed; the deny lists gained
.git, .github and .tmp; and a content security policy is sent.

Upgrading from 5.1 is a normal update: the database gains two tables and three
columns on first start. The first sign-in afterwards starts the tour once, and
the key fields stay locked until Administration › Security has been opened - the
check runs there by itself.