All Versions
- DSpace 7.x (Current Release)
- DSpace 8.x (Unreleased)
- DSpace 6.x (EOL)
- DSpace 5.x (EOL)
- More Versions...
...
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 . Running (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 . For example, running both on 'localhost' with HTTP works fine (and this is a common development setup), and this will work fine.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)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).dspace.ui.url
" configuration on the Backend matches the public URL of the 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.