| # this specifies how the sai-web server operates
{
"vhosts": [{
# this has no special meaning but needs to be unique
"name": "unixsktw",
"unix-socket": 1,
# this should be owned by sai and allow group access from
# whatever group your webserver runs under
"unix-socket-perms": "sai:apache",
# multiple vhosts can exist with different unix skt names
"interface": "/var/run/sai",
# required for avatar cache
"enable-client-ssl": "on",
"mounts": [
{
"mountpoint": "/sai",
"default": "index.html",
"origin": "file:///usr/local/share/sai/assets",
"origin": "callback://com-warmcat-sai",
"cache-max-age": "7200",
"cache-reuse": "1",
"cache-revalidate": "0",
"cache-intermediaries": "0",
"extra-mimetypes": {
".zip": "application/zip",
".map": "application/json",
".ttf": "application/x-font-ttf"
}
},
{
# semi-static cached avatar icons
"mountpoint": "/sai/avatar",
"origin": "callback://avatar-proxy",
"cache-max-age": "2400",
"cache-reuse": "1",
"cache-revalidate": "0",
"cache-intermediaries": "0"
}
],
#
# these headers, which will be sent on every transaction, make
# recent browsers definitively ban any external script sources,
# no matter what might manage to get injected later in the
# page. It's a last line of defence against any successful XSS.
#
"headers": [{
"content-security-policy": "default-src 'none'; img-src 'self' data:; script-src 'self'; font-src 'self'; style-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self';",
"x-content-type-options": "nosniff",
"x-xss-protection": "1; mode=block",
"referrer-policy": "no-referrer"
}],
"ws-protocols": [
{"com-warmcat-sai": {
# this is the lhs of the path to use, not a full filepath
# the events go in ...-events.sqlite3 and the related
# info for an event goes in its own database file in
# ...-event-xxxx.sqlite3 where xxxx is the event uuid.
#
"database": "/srv/sai/sai-master",
# Unix socket sai-server serves its control link on:
# the same "sockpath" as in sai-server's conf. It is
# owned by sai-server's uid:gid with mode 0660, so the
# user sai-web runs as (see ../conf) must be that user
# or a member of that group, eg,
#
# usermod -a -G apache sai
#
# If unset, the abstract-namespace socket
# @com.warmcat.sai-websrv is used, which any local user
# can connect to.
#
"sockpath": "/var/run/sai-websrv",
# Optional: the projects (repo names) this vhost shows,
# as a comma-separated list. Browsers, rss feeds,
# status badges and artifact links on this vhost then
# behave as if no other project exists. Without it,
# the vhost shows every project.
#
# To offer different canned views of the one sai-server,
# copy this whole vhost with its own "name", a different
# unix socket "interface" path and different "projects",
# keeping "database" and "sockpath" the same. Then
# point each front-end vhost's /sai proxy mount at the
# socket for the view it should show (the UI expects to
# be at /sai, so views go on different hostnames).
#
#"projects": "libwebsockets, sai",
# sai-web does NO auth of its own: no JWK, no JWT
# validation, no grant logic. It learns the login
# state from the x-lws-login-* headers the lws-login
# interceptor (running in the front-end lwsws
# process) injects and the reverse proxy forwards to
# us. So sai-web's /sai mount in the front-end must
# be a proxy mount with lws-login wired as its
# interceptor, and that interceptor's pmo is the one
# place the grant name (eg lws-sai) lives:
#
# front-end (lwsws) vhost:
# { "mountpoint": "/sai",
# "origin": "http://+/var/run/sai:/sai",
# "interceptor-path": "/lws-login-sai" },
# { "mountpoint": "/lws-login-sai",
# "origin": "callback://lws-login",
# "protocol": "lws-login",
# "pmo": [{ "service-name": "lws-sai" }] }
#
# sai-web then reads x-lws-login-admin:0/1 at WS
# establish. Without the interceptor, sai-web sees no
# header and treats the user as not having admin rights.
#
# sai-web also fails closed around the header itself:
# it is only honoured when exactly one copy is present
# (duplicates could be a client-supplied spoof winning
# first-match) and the connection arrived on this unix
# socket, ie it came through the front-end proxy and
# not from something reaching a listen directly. If
# you expose sai-web on a TCP vhost, admin ops will
# silently stop working by design.
# template HTML to use for this vhost. You'd normally
# copy this to gitohashi-vhostname.html and modify it
# to show the content, logos, links, fonts, css etc for
# your vhost. It's not served directly but read from
# the filesystem. Although it's cached in memory by
# gitohashi, it checks for changes and reloads if
# changed automatically.
#
# Putting logos etc as svg in css is highly recommended,
# like fonts these can be transferred once with a loose
# caching policy. So in practice they cost very little,
# and allow the browser to compose the page without
# delay.
#
"html-file": "/usr/local/share/gitohashi/templates/gitohashi-example.html",
#
# vpath required at start of links into this vhost's
# gitohashi content for example if an external http
# server is proxying us, and has been told to direct
# URLs starting "/git" to us, this should be set to
# "/git/" so URLs we generate referring to our own pages
# can work.
#
"vpath": "/sai/",
#
# url mountpoint for the avatar cache
#
"avatar-url": "/sai/avatar/",
#
# libjsgit2 JSON cache... this
# should not be directly served
#
"cache-base": "/var/cache/libjsongit2",
#
# restrict the JSON cache size
# to 2GB
#
"cache-size": "2000000000",
#
# optional flags, b0 = 1 = blog mode
#
"flags": 0
#"blog-repo-name": "myrepo"
},
"avatar-proxy": {
"remote-base": "https://www.gravatar.com/avatar/",
#
# this dir is served via avatar-proxy
#
"cache-dir": "/var/cache/libjsongit2"
}
}
]
}
]
}
|