controls. Why is that a good idea, you ask? Because it is a safe
presumption that only someone with direct file access to the repository
database file could be using the resulting web interface. Anyone who can
modify the repo DB directly could give themselves any and all access
with a SQL query, or even by direct file manipulation; no amount of
access control matters to such a user.

(Contrast the [./server/ | many <i>other</i> ways] of setting Fossil up
as an HTTP server, where the repo DB is on the other side of the HTTP
server wall, inaccessible by all means other than Fossil's own
mediation. For this reason, the "localhost bypasses access control"
policy does <i>not</i> apply to these other interfaces. That is a very
good thing, since without this difference in policy, it would be unsafe
to bind a [/help?cmd=server | <b>fossil server</b>] instance to
localhost on a high-numbered port and then reverse-proxy it out to the
world via HTTPS, a practice this author does engage in, with confidence.)

Once you are finished configuring Fossil, you may safely Control-C out
of the <b>fossil&nbsp;ui</b> command to shut down this privileged
built-in web server.

<h2 id="sharing">Sharing Changes</h2>

When [./concepts.wiki#workflow|autosync] is turned off,