Page History
...
Property: |
|
Example Value: |
|
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 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 NOTE #3: Although subpath must match, the Origin header itself sent from Angular will never contain a subpath. So if the dspace.ui.url config property ever changes to include a subpath like /myapp, then the expected origin will need to be added to (Requires reboot of servlet container, e.g. Tomcat, to reload) |
Property: |
|
Example Value: |
|
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) |
Property: |
|
Example Value: |
|
Informational Note: | This property determines the max embeddepth for a FullProjection. This is also used by the SpecificLevelProjection |
Property: |
|
Example Value: |
|
Informational Note: | This property determines the max embed depth for a SpecificLevelProjection. Usually, this should be kept as-is for best performance. |
Property: |
|
Example Value: |
|
Informational Note: | Define which configuration properties are exposed through the 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. |
...
DSpace Python REST Client Library
The Library Code is a DSpace Platinum certified Service Provider. They created a python library to use the REST-API of DSpace 7 and upwards out of python: https://github.com/the-library-code/dspace-rest-python.