Page History

...

• 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 when necessary (see previous bullet).
• Verify that your "dspace.server.url" configuration on the Backend matches the primary URL of the REST API (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, and it must not end in a trailing slash (e.g. "https://api7.dspace.org/server" is valid, but  "https://api7.dspace.org/server/" may cause problems).
• Verify that your "dspace.ui.url" configuration on the Backend matches the primary 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, and it must not end in a trailing slash (e.g. "https://demo7.dspace.org" is valid, but "https://demo7.dspace.org/" may cause problems).
• Verify that nothing (e.g. a proxy) is blocking Cookies and HTTP Headers from being passed between the UI and REST API.  DSpace's CSRF protection relies on the client (User Interface) being able to return both a valid DSPACE-XSRF-COOKIE cookie and a matching X-XSRF-TOKEN header back to the REST API for validation. See our REST Contract for more details https://github.com/DSpace/RestContract/blob/main/csrf-tokens.md
• 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

...