REST API

Example Value:

rest.cors.allowed-origins = ${dspace.ui.url}

Informational Note:

Allowed Cross-Origin-Resource-Sharing (CORS) origins (in "Access-Control-Allow-Origin" header). Only these origins (client URLs) can successfully authenticate with your REST API via a web browser. Defaults to ${dspace.ui.url} if unspecified (as the UI must have access to the REST API).  If you customize that setting, MAKE SURE TO include ${dspace.ui.url} in that setting if you wish to continue trusting the UI.

Multiple allowed origin URLs may be comma separated (or this configuration can be defined multiple times). Wildcard value (*) is NOT SUPPORTED.

Keep in mind any URLs added to this setting must be an exact match with the origin: mode (http vs https), domain, port, and subpath(s) all must match.. So, for example, these URLs are all considered different origins: "http://mydspace.edu", "http://mydspace.edu:4000" (different port), "https://mydspace.edu" (http vs https), "https://myapp.mydspace.edu" (different domain), and "https://mydspace.edu/myapp" (different subpath).

NOTE #1: Development or command-line tools may not use CORS and may therefore bypass this configuration.  CORS does not provide protection to the REST API / server webapp. Instead, its role is to protect browser-based clients from cookie stealing or other Javascript-based attacks. All modern web browsers use CORS to protect their users from such attacks. Therefore DSpace's CORS support is used to protect users who access the REST API via a web browser application, such as the DSpace UI or custom built Javascript tools/scripts.

NOTE #2: If you modify this value to allow additional UIs (or Javascript tools) to access your REST API, then you may also need to modify proxies.trusted.ipranges to trust the IP address of each UI.  Modifying trusted proxies is only necessary if the X-FORWARDED-FOR header must be trusted from each additional UIs. (The DSpace UI currently requires the X-FORWARDED-FOR header to be trusted). By default, proxies.trusted.ipranges will only trust the IP address of the ${dspace.ui.url} configuration.

(Requires reboot of servlet container, e.g. Tomcat, to reload)

Example Value:

rest.cors.allow-credentials = true

Informational Note:

Whether or not to allow credentials (e.g. cookies) sent by the client/browser in CORS requests (in "Access-Control-Allow-Credentials" header).

For DSpace, this MUST be set to "true" to support CSRF checks (which use Cookies) and external authentication via Shibboleth (and similar). Defaults to "true" if unspecified. (Requires reboot of servlet container, e.g. Tomcat, to reload)

Example Value:

rest.projections.full.max = 2

Informational Note:

This property determines the max embeddepth for a FullProjection. This is also used by the SpecificLevelProjection
as a fallback in case the property is defined on the bean. Usually, this should be kept as-is for best performance.

Example Value:

rest.projection.specificLevel.maxEmbed = 5

Informational Note:

This property determines the max embed depth for a SpecificLevelProjection. Usually, this should be kept as-is for best performance.

Example Value:

rest.properties.exposed = plugin.named.org.dspace.curate.CurationTask
rest.properties.exposed = google.analytics.key

Informational Note:

Define which configuration properties are exposed through the http://<dspace.server.url>/api/config/properties/ REST API endpoint. 

If a rest request is made for a property which exists, but isn't listed here, the server will respond that the property wasn't found. This property can be defined multiple times to allow access to multiple configuration properties.

Generally, speaking, it is ONLY recommended to expose configuration settings where they are necessary for the UI or client, as exposing too many configurations could be a security issue.  This is why we only expose the two above settings by default.