Page History

...

Common Installation Issues

...

Seeing "CORS error" or "Invalid CORS request"

If you are seeing a 403 Forbidden error every time you try to login (with a known, valid password), then it's likely you have a configuration issue which is blocking the frontend from accessing the backend.CORS error in your browser, this means that you are accessing the REST API via an "untrusted" client application.  To fix this error, you must change your REST API / Backend configuration to trust the application.

• 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 Verify that the URLs in your Frontend's src/environments/environment.common.ts  EXACTLY MATCH the Backend's local.cfg Backend's dspace.ui.url MUST reference the same URL as the Frontend's "ui" configuration section.  Modes (http vs https), portsdomain, port, hostnames and nameSpace subpath(or paths) all must all match.
• Keep in mind if you are using port 80 or port 443, those can be left off the dspace.ui.url configuration, as they are the default ports for HTTP and HTTPS respectively.
• Backend's dspace.server.url MUST reference the same URL as the Frontend's "rest" configuration section.  Modes (http vs https), ports, hostnames and nameSpace (or path) must all match.
  • Keep in mind if you are using port 80 or port 443, those can be left off the dspace.server.url configuration, as they are the default ports for HTTP and HTTPS respectively.
• 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).

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

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

First, double check that you are seeing that exact message.  403 Forbidden can be thrown in a variety of scenarios...it could be page that requires a login, you could have entered an invalid username or password, or you could even be seeing a CORS error (see previous issue for how to solve that). 

If you are seeing the message "Invalid CSRF Token" message (especially on every login), this is usually the result of a configuration / installation issue.

Here's some things you should double check:

• 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" with a value of "SameSite=Lax".  This setting means that the cookie will not be sent to any other domains & this will block all logins from any domain that is not the same as the REST API.  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 works fine (and this is a common development setup).
  • In order to allow for cross-domain logins, you MUST enable HTTPS on the REST API. This will result in the "DSPACE-XSRF-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)
• 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 the 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.mdIf the above all match, you can also double check the CORS (Cross-origin resource sharing) configuration on the Backend to ensure that it includes the Frontend's URLrest.cors.allowed-origins specifies the client URLs which are allowed login access to the Backend. It MUST include the Frontend URL (though by default it does) or else the backend will block all logins coming from the frontend.