Dspace 7 ERROR on Production

[Juan López]

Hello!

We're haven issues with an installation of DSpace 7.6.1.

When we were on development mode the service was working as expected. We had a DNS with https and the front-end/back-end communication was set like this:

ui:

  ssl: false

  host: localhost

  port: 4000

  nameSpace: /

  rateLimiter:

    windowMs: 60000

    max:

  useProxies: true

rest:

  ssl: true

  host: test.mydspace.com

  port: 443

  nameSpace: /server

However, now that we are in production, we've changed the URLs in the front and back configuration files, and the service is working really slow and throwing communications errors from time to time between the backend and frontend.

The IT team has detected that this errors are happening because the front-end is passing through the WAF everytime it needs to get data from the back-end.

We've tried setting the rest-host to "localhost", but DSpace won't work after that.

Is there a way to make both, the frontend and backend point to "localhost" so the backend does not have to go through the firewall?

Or is there another possible configuration for this to work smoothly?

Best regards,

Juan

[DSpace Technical Support]

Hi Juan,

Because the frontend is a *Javascript application* (built on Angular.io), it runs in a user's browser by default (except when Angular's server-side rendering is triggered).  

This means that (at least some of the time) your users are running the frontend in their browser and only sending requests to your backend (REST API).

This is why trying to set "rest" to "localhost" won't work.  Because, in that scenario, your users are running the frontend in their browser and it's trying to connect to "localhost" (which would be the user's own machine, and *not* your REST API).

This is exactly why the REST API always needs to be configured as a publicly available URL...because all your users are sending requests to the REST API directly whenever they are running the UI in their browser.

In terms of whether the frontend needs to send every request through your WAF (web application firewall)...that's harder to answer.  If every external request is going through the WAF, then these requests will need to as well.  But, maybe there's some way to change your firewall settings to "trust" requests coming from your frontend?   I don't know the answer here, but maybe someone else on this list may have ideas if they've dealt with this before.

You also may want to review the "Common Installation Issues" documentation in case some of the communication errors you are seeing are ones noted there.  We also have an ongoing discussion related to performance of Server Side Rendering (of the frontend) which could be of interest: https://github.com/DSpace/dspace-angular/issues/3110

Hopefully those give you a few ideas to start with.  Maybe others on this list will have additional suggestions.

Tim

[Juan López]

Hi Tim!

Thank you for the response. So does this mean that the IT team needs to change the WAF configuration to fit the needs of the DSpace architecture?

Juan.

[Juan López]

Forgot to mention, we have SSR set in our DSpace.

[DSpace Technical Support]

Hi Juan,

It's difficult for me to provide advice on your WAF (web application firewall) configuration or setup. All I can say is that, if your WAF doesn't support Javascript-based web applications, then it may require updates.

Because the DSpace User Interface is an Angular/Javascript application, it *must* run in your users' browsers. This means that your users' browsers will be making direct requests to your backend (REST API) from wherever they are in the world.   The backend URL that your users' browsers will use is the one configured in your "rest:" section of the config.*.yml settings.  So, this URL can never be localhost...as that cannot be accessed from all over the world.

It's worth noting that SSR (server side rendering) is the only scenario where the frontend code is running on your server and directly accessing the backend (also on your server).  However SSR is primarily used for SEO and to render the first page that an anonymous user sees when they access your site.  After that, Angular automatically switches users from that SSR generated page over to the JavaScript application running in their browser. (In other words, your authenticated users, especially administrators will mostly *never* be using SSR.  SSR is mostly for indexing bots and some anonymous users.)  For more on how Angular SSR works, see: https://v17.angular.io/guide/ssr

Tim