Web Assets#
The Curity Identity Server can serve static web assets (e.g. CSS, images, static HTML pages) from the webroot directory, which is located
at usr/share/webroot.
By default, request paths will map to a webroot resource only in case no configured routes match.
For example, if a request arrives on path /hello/foo, the server will check if there is any configured route matching that
path. That may match in case, as an example, the OAuth Anonymous Endpoint was configured to /hello or /hello/foo.
However, if no matches are found, the server will try to locate a file under <webroot>/hello/foo and serve that
if a file is found, or error with the 404 status code and an error page.
We recommend placing all resources under the <webroot>/assets/ directory in case you do not configure another path for the static resources,
since that allows the server to more efficiently locate resources, as it does not need to first check if any configured
routes match the /assets request path.
If you need the /assets request path to match a configured route, you must configure a custom static-resource-root-path
(see below for details).
If the request path matches a directory, say <webroot>/assets/pages, then the server will attempt to serve
the index.html page under that if the request accepts the text/html content-type (i.e. <webroot>/assets/pages/index.html
in this example).
Configuring a static resource root path#
It is possible to only attempt to find a static resource in case the request path starts with a specific path.
That can be done in the Server General Settings, under Static Resource Root Path
(see environment ).
Suppose the Static Resource Root Path is configured to /web-resources. In this case,
the server will only serve a static resource for requests whose path starts with /web-resources/:
a request with path /web-resources/greetings/hello.txt will map to resource <webroot>/greetings/hello.txt.
There is an exception to the above for the root path /, as explained in the next section.
This may help with performance since the Server will know to directly search for static resources under the configured path without first trying the configured paths.
Notice that the Static Resource Root Path is removed from the mapped resource file.
Root path asset#
If a request arrives at the / path, the Server attempts to serve the file <webroot>/index.html.
In case static-resource-root-path has been configured, it will first redirect the client to the configured root
path (where the server should also find the file <webroot>/index.html if it exists).
It is good practice to always store a file at <webroot>/index.html, so that in case any visitors
arrive at the server’s root path, they can see some information about it.
Content-Type Negotiation#
The Curity Identity Server honours the Accept header, hence will only serve a web asset if it can detect the media-type is acceptable
for the client, according to the Accept header it sent (or */* if the client did not send that header).
A file’s Content-Type is inferred from its name and extension if possible, or from its contents (only a few bytes are used)
in certain cases.
It is possible to configure how this detection occurs, in the rare case that it becomes necessary, by providing a Apache Tika configuration file.
The path to the Tika Configuration must be set by the tika.config system property or TIKA_CONFIG environment variable.
Dynamic Applications#
In case simple static web assets are not enough for your situation, consider writing an Application Plugin .