# Example Kore configuration

# Below you will find all available configuration
# options for Kore. Options which have a default value
# and can be left out of the configuration are commented
# out with their default value specified.

# Maximum length to queue pending connections (see listen(2))
# MUST be set before any bind directive.
#socket_backlog			5000

# Server configuration.
bind		127.0.0.1 443

# The path worker processes will chroot into after starting.
chroot		/home/joris/src/kore

# Worker processes will run as the specified user.
runas		joris

# How many worker processes Kore will spawn. If the directive
# worker_set_affinity is set to 1 (the default) Kore will automatically
# pin these worker processes to different CPU cores in your system.
# NOTE: If you set this to the maximum number of cores you have
# in your system (or more) you might consider turning off affinity
# if you are running CPU heavy services on the same machine.
workers		4

# The number of active connections each worker can handle.
# You might have to tweak this number based on your hardware.
#worker_max_connections		250

# Limit of maximum open files per worker.
#worker_rlimit_nofiles		1024

# Limit the number of new connections a worker can accept
# in a single event loop. By default Kore will accept as
# many new connections it can up to worker_max_connections.
#
# NOTE: If you are running benchmark tools that throw all
# connections at Kore at the same time (when they are less
# then worker_max_connections) or you have an actual reason
# to not spend too much time in the accept loop this setting
# will make a HUGE positive difference.
#
# This is disabled by default. If you wish to enable this
# specify the number of connections a worker will accept
# before returning from the accept loop.
#worker_accept_threshold		0

# Workers bind themselves to a single CPU by default.
# Turn this off by setting this option to 0
#worker_set_affinity		1

# Store the pid of the main process in this file.
#pidfile	kore.pid

# If TLS is enabled you can specify a file where Kore will read
# initial entropy from and save entropy towards when exiting.
#
# Note that if you enable this you must provide the first iteration
# of this file by generating 1024 cryptographically safe random bytes
# and writing them to the file specified.
#
# Kore will refuse to start if the specified file does not exist,
# is of the wrong size or cannot be opened in anyway.
#
# NOTE: This file location must be inside your chrooted environment.
#rand_file	random.data

# Filemap settings
#	filemap_index	Name of the file to be used as the directory
#				index for a filemap.
#filemap_index index.html

# HTTP specific settings.
#	http_header_max		Maximum size of HTTP headers (in bytes).
#
#	http_body_max		Maximum size of an HTTP body (in bytes).
#				If set to 0 disallows requests with a body
#				all together.
#
#	http_body_disk_offload	Number of bytes after which Kore will use
#				a temporary file to hold the HTTP body
#				instead of holding it in memory. If set to
#				0 no disk offloading will be done. This is
#				turned off by default.
#
#	http_body_disk_path	Path where Kore will store any temporary
#				HTTP body files.
#
#	http_keepalive_time	Maximum seconds an HTTP connection can be
#				kept alive by the browser.
#				(Set to 0 to disable keepalive completely).
#
#	http_hsts_enable	Send Strict Transport Security header in
#				all responses. Parameter is the age.
#				(Set to 0 to disable sending this header).
#
#	http_request_limit	Limit the number of HTTP requests workers
#				can queue up.
#
#	http_request_ms		The number of milliseconds workers can max
#				spend inside the HTTP processing loop.
#
#http_header_max	4096
#http_body_max		1024000
#http_keepalive_time	0
#http_hsts_enable	31536000
#http_request_limit	1000
#http_request_ms	10
#http_body_disk_offload	0
#http_body_disk_path	tmp_files

# Websocket specific settings.
#	websocket_maxframe	Specifies the maximum frame size we can receive
#	websocket_timeout	Specifies the time in seconds before a websocket
#				connection would be closed due to inactivity.
#websocket_maxframe	16384
#websocket_timeout	120

# Configure the number of available threads for background tasks.
#task_threads		2

# Load modules (you can load multiple at the same time).
# An additional parameter can be specified as the "onload" function
# which Kore will call when the module is loaded/reloaded.
load contrib/examples/generic/example.module	example_load

# Load a python file (if built with PYTHON=1)
#python_import src/index.py example_load

# Validators
#	validator	name	type	regex|function
#
validator	v_example	function	v_example_func
validator	v_regex		regex		^/test/[a-z]*$
validator	v_number	regex		^[0-9]*$
validator	v_session	function	v_session_validate

# Specify what TLS version to be used. Default is TLSv1.2
# Allowed values:
#	1.2 for TLSv1.2 (default)
#	1.0 for TLSv1.0
#	both for TLSv1.0 and TLSv1.2
#tls_version	1.2

# Specify the TLS ciphers that will be used.
#tls_cipher	ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!kRSA:!kDSA

# Required DH parameters for TLS.
#tls_dhparam	dh2048.pem

# Authentication configuration
#
# Using authentication blocks you can define a standard way for
# Kore to validate your users. In the example below we create
# a authentication block called auth_example, which requires
# a cookie (session_id) to be set.
#
# If no cookie is present or the cookie is not valid according
# to the set validator, Kore will redirect the browser to the
# URI set in authentication_uri.
#
# Page handlers can be bound to authentication by specifying
# authentication block at the end of the page directive (see below).
authentication auth_example {
	# The authentication type denotes the way the user should
	# be authenticated.
	#
	# Allow values:
	#	- cookie (checks for the cookie presence + pass to validator)
	#	- header (checks for header presence + pass to validator)
	#	- request (passes the http_request to the validator)
	#
	# Use cases for request could for example be IP based ACLs or
	# any other criteria that can be extracted from a http_request.
	#
	# The request type does not need an authentication_validator.
	#
	authentication_type		cookie

	# The name of whatever we are looking for.
	authentication_value		session_id

	# The validator that will be called to verify the cookie.
	# Note this is YOUR validator, Kore does not have built-in
	# session support. You must add this manually using your
	# preferred method (Storing it in postgres, redis, ...)
	authentication_validator	v_session

	# The URI Kore will redirect to if a authentication fails.
	# If this is not set, Kore will return a simple 403.
	authentication_uri		/private
}

# Domain configuration
#
# Each domain configuration starts with listing what domain
# the directives that follow are to be applied upon.
#
# Additionally you can specify the following in a domain configuration:
#
#	accesslog
#		- File where all requests are logged.
#	client_certificates [CA] [optional CRL]
#		- Require client certificates to be sent for the given
#		  CA with an optional CRL file.
#	client_verify_depth [depth]
#		- Configure the depth for x509 chain validation.
#		  By default 1.
#
# Handlers
#
# Handlers are either static (for fixed paths) or dynamic.
# Dynamic handlers take a POSIX regular expression as its path.
#
# Syntax:
#	handler		path		module_callback		[auth block]
#
# Note that the auth block is optional and if set will force Kore to
# authenticate the user according to the authentication block its settings
# before allowing access to the page.

# Example domain that responds to localhost.
domain localhost {
	certfile	cert/server.crt
	certkey		cert/server.key
	accesslog	/var/log/kore_access.log

	# Page handlers with no authentication required.
	static		/css/style.css		serve_style_css
	static		/			serve_index
	static		/intro.jpg		serve_intro
	static		/b64test		serve_b64test
	static		/upload			serve_file_upload
	static		/lock-test		serve_lock_test
	static		/validator		serve_validator
	static		/params-test		serve_params_test
	static		/private		serve_private

	# Page handlers with authentication.
	static		/private/test	serve_private_test	auth_example

	# Allow access to files from the directory static_files via
	# the /files/ URI.
	filemap		/files/			static_files

	# Configure /params-test POST to only accept the following parameters.
	# They are automatically tested against the validator listed.
	# If the validator would fail Kore will automatically remove the
	# failing parameter, indicating something was wrong with it.
	# Any parameters not present in the params block are also filtered out.
	params post /params-test {
		validate	test1		v_example
		validate	test2		v_regex
	}

	# Configure a GET parameter that /params-test can received. As before
	# this is validated against the validator and removed if validation
	# fails. All extra parameters in the GET query are filtered out.
	params get /params-test {
		validate	arg1		v_example
		validate	id		v_number
	}

	# Configure a params block for allowed parameters in the
	# querystring when performing a POST against /params-test.
	# You do this by prefixing the method with the qs: marker.
	# In the param blocks below we allow the parameter "post_id"
	# in the querystring validated by v_number when a POST is
	# done against the supplied URL.
	params qs:post /params-test {
		validate	post_id		v_number
	}
}

#domain domain.com {
#	certfile		cert/other/server.crt
#	certkey			cert/other/server.key
#	accesslog		/var/log/other_kore_access.log
#	client_certificates	cert/other/ca.crt
#	client_verify_depth	1

#	static		/css/style.css		serve_style_css
#	static		/			serve_index
#	dynamic		^/[a-z0-9_]*$		serve_profile
#}