# 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",

			# 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"
		}
		}
		]
		}
	]
}