Page History

...

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

Cannot login from the User Interface with a password that I know is valid

If you cannot login via the user interface with a valid password, you should check to see what underlying error is being returned by the REST API.  The easiest way to do this is by using your web browser's Dev Tools as described in our Troubleshoot an error guide (see the "Try this first" section for DSpace 7).

If the password is valid, more than likely you'll see the underlying error is "403 Forbidden" error with a message that says "Access is denied. Invalid CSRF Token" (see hints on solving this in the very next section)

"403 Forbidden" error with a message that says "Access is denied. Invalid CSRF Token"

First, double check that you are seeing that exact error message.  A 403 Forbidden error may be thrown in a variety of scenarios. For example, a 403 may be thrown if a page requires a login, if you have entered an invalid username or password, or even sometimes when there is a CORS error (see previous installation issue for how to solve that). 

...

1. If you site had been working, and this error seems random, it is possibly that DSPACE-XSRF-COOKIE cookie in your browser just got "out of sync" (this can occur if you are logging into the REST API and UI separately in the same browser).
   1. Logout and login & try the same action again.  If it works this time, then that cookie was just "out of sync".  If it fails a second time, then there is a likely configuration issue...see suggestions below.
2. Make sure your backend is running HTTPS!  This is the most common cause of this error.  The only scenario where you can run the backend in HTTP is when both the frontend & backend URLs are "localhost"-based URLs. If you need to be able to login to the REST API from other domains, then your Backend must be running HTTPS.  
   1. The reason for this HTTPS requirement is that most modern browsers will automatically block cross-domain cookies when using HTTP. Cross-domain cookies are required for successful authentication.  The only exception is when both the frontend and backend are using localhost URLs (as in that scenario the cookies no longer need to be sent cross-domain).  A more technical description of this behavior is in the sub-bullets below.
   1. 1. 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.
      2. 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)
3. 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).
4. 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).
5. 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).
6. 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
7. 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

...