Page History

...

• By default, the DSpace REST API / Backend will only trust the application at dspace.ui.url.  Therefore, you should first verify that your dspace.ui.url setting (in your local.cfg) exactly matches the public URL of your User Interface (i.e. the URL you see in the browser).  This must be an exact match: mode (http vs https), domain, port, and subpath(s) all must match.
• If you need to trust additional client applications / URLs, those MUST be added to the rest.cors.allowed-origins configuration. This should be comma-separated list of trusted URLs.  If you customize that setting, MAKE SURE TO include ${dspace.ui.url} in that setting if you wish to continue trusting the UI.  Again, keep in mind any URLs added to this setting must be an exact match: mode (http vs https), domain, port, and subpath(s) all must match.. So, for example, these URLs are all considered different applications: "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)See REST API for details on this configuration.

If you modify either of the above settings, you will need to restart Tomcat for the changes to take effect.

...

• If you need to be able to login to the REST API from other domains, then your Backend must be running HTTPS.  
  • If the REST API Backend is running HTTP, then it will always send the required DSPACE-XSRF-COOKIE cookie with a value of SameSite=Lax.  This setting means that the cookie will not be sent (by your browser) to any other domains. Effectively, this will block all logins from any domain that is not the same as the REST API (as this cookie will not be sent back to the REST API as required for CSRF validation).  In other words, running the REST API on HTTP is only possible if the User Interface is running on the exact same domain. For example, running both on 'localhost' with HTTP is a common development setup, and this will work fine.
  • In order to allow for cross-domain logins, you MUST enable HTTPS on the REST API. This will result in the DSPACE-XSRF-COOKIE cookie being set to SameSite=None; Secure.  This setting means the cookie will be sent cross domain, but only for HTTPS requests. It also allows the user interface (or other client applications) to be on any domain, provided that the domain is trusted by CORS (see rest.cors.allowed-origins setting in REST API)
• Verify that your User Interface's "rest" section matches the value of "dspace.server.url" configuration on the Backend.  This simply ensures your UI is sending requests to the correct REST API.  Also pay close attention that both specify HTTPS (see previous bullet).
• Verify that your "dspace.ui.url" configuration on the Backend matches the public URL of your User Interface (i.e. the URL you see in the browser). This must be an exact match: mode (http vs https), domain, port, and subpath(s) all must match.
• If you are running a custom application, or accessing the REST API from the command-line (or other third party tool like Postman), you MUST ensure you are sending the CSRF token on every modifying request.  See our REST Contract for more details https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md

...