Issues with dSpace10.0 installation behind IIS reverse proxy

[Vincent B.]

Hi everyone,

I have been scratching my head about two frontend issues for hours.

- ERR_INVALID_ADDRESS

- Some localhost remaining in main.js

This is my first installation of dSpace. Here are some infromations about the server

- Windows server 2022

- nvm 24.15.0

- using pm2 and environment variables and node.exe for debug

- IIS (10.0.xxxx)) reverse proxy with HTTPS

Here is my dspace-ui.json

{
    "apps": [
        {
           "name": "dspace-ui",
           "cwd": "E:\\dspace-ui-deploy",
           "script": "dist\\server\\main.js",
           "instances": "max",
           "exec_mode": "cluster",
           "env": {
              "NODE_ENV": "production",
              "DSPACE_UI_SSL" : "false",
              "DSPACE_UI_HOST" : "127.0.0.1",
              "DSPACE_UI_PORT": "4000",
              "DSPACE_UI_SSL" : "false",
              "DSPACE_UI_NAMESPACE" : "/",
              "DSPACE_UI_SSL" : "false",
              "DSPACE_UI_BASEURL" : "https://[our frontend url]",
              "DSPACE_REST_SSL" : "true",
              "DSPACE_REST_HOST" : "[our backend url]",
              "DSPACE_REST_PORT" : "443",
              "DSPACE_REST_NAMESPACE" : "/server",
           }
        }
    ]
}

Those are replicated in Windows environment variables.

After build and copying the built code to dspace-ui-deploy-dist I have two errors.

First is related to having the port in the forwarded IP.

ValidationError: An invalid 'request.ip' (192.168.24.13:54170) was detected. Consider passing a custom 'keyGenerator' function to the rate limiter. See https://express-rate-limit.github.io/ERR_ERL_INVALID_IP_ADDRESS/ for more information.
    at Object.ip (E:\dspace-ui-deploy\dist\server\main.js:1:3829713)
    at Object.wrappedValidations.<computed> [as ip] (E:\dspace-ui-deploy\dist\server\main.js:1:3837557)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3839154
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (E:\dspace-ui-deploy\dist\server\main.js:1:3806369)
    at _next (E:\dspace-ui-deploy\dist\server\main.js:1:3806609)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3806728
    at new ZoneAwarePromise (E:\dspace-ui-deploy\dist\server\main.js:1:3716681)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3806545
    at Object.keyGenerator (E:\dspace-ui-deploy\dist\server\main.js:1:3839558) {
  code: 'ERR_ERL_INVALID_IP_ADDRESS',
  help: 'https://express-rate-limit.github.io/ERR_ERL_INVALID_IP_ADDRESS/'
}

The issue is I have no idea where to set up this custom KeyGenerator to strip the IP from the port. Or should I fix it at reverse proxy level?

Second issue is more troublesome.

ERROR: URL with hostname "localhost" is not allowed.Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor.
Error in server-side rendering (SSR)
Error details :  Error: URL with hostname "localhost" is not allowed.
    at validateUrl (E:\dspace-ui-deploy\dist\server\main.js:1:8227592)
    at E:\dspace-ui-deploy\dist\server\main.js:1:8227653
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (E:\dspace-ui-deploy\dist\server\main.js:1:3993125)
    at _next (E:\dspace-ui-deploy\dist\server\main.js:1:3993350)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993469
    at new ZoneAwarePromise (E:\dspace-ui-deploy\dist\server\main.js:1:3716681)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993286
    at CommonEngine.render (E:\dspace-ui-deploy\dist\server\main.js:1:8229294)
    at serverSideRender (E:\dspace-ui-deploy\dist\server\main.js:1:8242424)
Falling back to serving direct client-side rendering (CSR).
GET /home 200 12.333 ms - 1115
Error: URL with hostname "localhost" is not allowed.
    at validateUrl (E:\dspace-ui-deploy\dist\server\main.js:1:8227592)
    at E:\dspace-ui-deploy\dist\server\main.js:1:8227653
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (E:\dspace-ui-deploy\dist\server\main.js:1:3993125)
    at _next (E:\dspace-ui-deploy\dist\server\main.js:1:3993350)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993469
    at new ZoneAwarePromise (E:\dspace-ui-deploy\dist\server\main.js:1:3716681)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993286
    at CommonEngine.render (E:\dspace-ui-deploy\dist\server\main.js:1:8229294)
    at serverSideRender (E:\dspace-ui-deploy\dist\server\main.js:1:8242424)
ERROR: URL with hostname "localhost" is not allowed.Please provide a list of allowed hosts in the "allowedHosts" option in the "CommonEngine" constructor.
Error in server-side rendering (SSR)
Error details :  Error: URL with hostname "localhost" is not allowed.
    at validateUrl (E:\dspace-ui-deploy\dist\server\main.js:1:8227592)
    at E:\dspace-ui-deploy\dist\server\main.js:1:8227653
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (E:\dspace-ui-deploy\dist\server\main.js:1:3993125)
    at _next (E:\dspace-ui-deploy\dist\server\main.js:1:3993350)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993469
    at new ZoneAwarePromise (E:\dspace-ui-deploy\dist\server\main.js:1:3716681)
    at E:\dspace-ui-deploy\dist\server\main.js:1:3993286
    at CommonEngine.render (E:\dspace-ui-deploy\dist\server\main.js:1:8229294)
    at serverSideRender (E:\dspace-ui-deploy\dist\server\main.js:1:8242424)
Falling back to serving direct client-side rendering (CSR).

I checked all my configuration variables and they are consistent with the dspce-ui.json.

I still get some calls to localhost from main.js

Like here,

 ...       

class sU {
            constructor() {
                this.production = !1,
                this.debug = !1,
                this.ui = {
                    ssl: !1,
                    host: "localhost",
                    port: 4e3,
                    nameSpace: "/",
                    baseUrl: "http://localhost:4000",
                    rateLimiter: {
                        windowMs: 6e4,
                        limit: 500,
                        ipv6Subnet: 56
                    },
                    useProxies: !0
                },

...

The generated config.json  seems correct

  "ui": {
    "ssl": false,
    "host": "localhost",
    "port": 4000,
    "nameSpace": "/",
    "baseUrl": "https://[our frontend url] "
  }
}

Does anyone have an idea of why I get those localhost in the main.js and what could be the root of the problem?

Thanks a lot.

Best,

Vincent

[Vincent B.]

Hi everyone,

To clarify, I used both localhost and 127.0.0.1 as DSPACE_UI_HOST.
I got the same result after building the frontend leading me to think that the localhost baseUrl in main.js were not linked to our configuration variables.

Are the calls to http://localhost:4000 hardcoded in main.js or are they linked to some server variable like HTTP_X_FORWARDED_HOST or HTTP_X_FORWARDED_PROTO?
Setting up the two http variables fixed the issue for the backend but not for the frontend.

I could also be a malfunction in my npm build...


Any help would be greatly appreciated. What kind of information should I add to this conversation?

Best,

Vincent

[Michael Plate]

Hi,

Am 22.07.26 um 14:51 schrieb Vincent B.:

> Hi everyone,
>
> To clarify, I used both localhost and 127.0.0.1 as DSPACE_UI_HOST.

[…]

- I don't have any experience with DSpace on Windows -

break it down.
Did you run

npm run start:dev

in the dspace-angular-dspace-xx (DSpace-UI) with success ?

Before deploying with pm2, try

node dist/server/main.js

in dspace-angular-dspace-xx .

We use also pm2, but we do not have any of the environment variables
beside "NODE_ENV": "production" …

Michael

[Vincent B.]

Thanks a lot for your feedback.

npm run start:dev

Runs fine and without issues, with a fully functional UI

But for some reason node dist/server/main.js (adjusted for Windows) from the dspace source folder and dspace-ui-deploy folder bot gives me the same error as previously

Vincent

[Michael Plate]

Hi,

Am 22.07.26 um 16:39 schrieb Vincent B.:

>
> Thanks a lot for your feedback.

> *
> *
> *npm run start:dev*

>
> Runs fine and without issues, with a fully functional UI
>

> rpnrunstartdev-success.png
>
> But for some reason *node dist/server/main.js* (adjusted for Windows)

> from the dspace source folder and dspace-ui-deploy folder bot gives me
> the same error as previously

[…]

and you have copied the config.example.yml to config.yml in the config
folder of the UI and adjusted the "host" to the name of your machine ?

"allowedHosts" seems to be part of webpack.

Can you retrieve the server backend (http(s)://<your-machine>/server )
in the browser ?

Michael

[Vincent B.]

Hi,

Thanks again.

On Wednesday, July 22, 2026 at 5:14:16 PM UTC+2 Michael Plate wrote:

Hi,

Am 22.07.26 um 16:39 schrieb Vincent B.:
>
> Thanks a lot for your feedback.
> *
> *
> *npm run start:dev*
>
> Runs fine and without issues, with a fully functional UI
>
> rpnrunstartdev-success.png
>
> But for some reason *node dist/server/main.js* (adjusted for Windows)
> from the dspace source folder and dspace-ui-deploy folder bot gives me
> the same error as previously

[…]

and you have copied the config.example.yml to config.yml in the config
folder of the UI and adjusted the "host" to the name of your machine ?

I didn't at the moment because the configuration documentation specified to pick one option between environment variables and config files.

I did try both options though: config files and/or environment variables.

All led to the same issues.

 

"allowedHosts" seems to be part of webpack.

Should I configure some allowedHosts variable somewhere?

 

Can you retrieve the server backend (http(s)://<your-machine>/server )
in the browser ?

Yes, the backend is working fine and is accessible from the browser of the frontend UI VM.

Here is the Response Headers section from the backend

200 success

cache-control: no-cache, no-store, max-age=0, must-revalidate
content-language: en
content-length: 9901
content-type: application/hal+json;charset=UTF-8
date: Wed, 22 Jul 2026 16:03:48 GMT
dspace-xsrf-token: [obfuscated]
expires: 0
pragma: no-cache
strict-transport-security: max-age=31536000 ; includeSubDomains
vary: Access-Control-Request-Headers
x-content-type-options: nosniff
x-frame-options: DENY
x-powered-by: ARR/3.0
x-xss-protection: 0

 

Michael

Vincent 

[Michael Plate]

Hi,

Am 22.07.26 um 18:09 schrieb Vincent B.:
> Hi,
>
[…]

> Should I configure some allowedHosts variable somewhere?

[…]

I used this from time to time:

"disableHostCheck": true

also is should not be used besides the dev environment.

open angular.json, search for

serve->options

and add it there.

Good luck,

Michael

[Vincent B.]

So I tried like you said,

        "serve": {
          "builder": "@angular-builders/custom-webpack:dev-server",
          "options": {
            "buildTarget": "dspace-angular:build",
            "port": 4000,
            "disableHostCheck": true
          },

No luck.

Also tried to delete the modules, the cache, do a npm clean install, ...

Nothing changes.

Is there a way to get in touch with dSpace support for a troublehooting session?

Another option, should I install dSpace 9 instead?

Best,

Vincent

[Michael Plate]

Hi Vincent,

Am 24.07.26 um 16:32 schrieb Vincent B.:
[…]

> Another option, should I install dSpace 9 instead?

I'am running 3 DSpace 10 (testwise) w/o any of your problems, so you
might give node in an older version a try, first (mine ist v20.19.2).

Michael

[Joshua Kim]

Hi,

I have the same issue in our DSpace 9.3 production. Did you find a solution for this? In the .pm2 log files, there are many errors related to this.

[Gary Hsu]

Hi Vicent,

I might have encoutered a similar issue that the localhost is not allowed.

At that time, I did find the solution to solve my problem and hopefully it is applied to yours.

add http://localhost:4000/ to the whitelist
We may have multiple frontends listening to the backend. For example, one public URL for the production site and one localhost for the development site. We need to add the extra frontend to the list

cd /dspace/config sudo nano local.cfg

add localhost in the local.cfg

##################### # REST API SETTINGS # ##################### # Allowed Cross-Origin-Resource-Sharing (CORS) origins (in "Access-Control-Allow-Origin" header). # Only these origins (client URLs) can successfully authenticate with your REST API. # Defaults to ${dspace.ui.url} if unspecified (as the UI must have access to the REST API). # Multiple allowed origin URLs may be comma separated. Wildcard value (*) is NOT SUPPORTED. # (Requires reboot of servlet container, e.g. Tomcat, to reload) # When an external authentication system is involved like Shibboleth some browsers (i.e. Safari) include # in the request the Origin header with the url of the IdP. In such case you need to allow also the IdP to # avoid trouble for such browsers (i.e. rest.cors.allowed-origins = ${dspace.ui.url}, https://samltest.id ) rest.cors.allowed-origins = ${dspace.ui.url}, http://localhost:4000

restart tomcat

sudo systemctl restart tomcat10.service 

On Monday, July 20, 2026 at 4:15:49 PM UTC+2 Vincent B. wrote:

[Vincent B.]

Hi everyone,

I apologize for the lack of update as I am unsure of the solution that I found.

What I did was

- Add and configure CYPRESS_BASE_URL and set it to https://[frontend url] to get rid of some localhost calls in main.js

- edit server.ts and add localhost to allowedHosts line 256

The second one seems more like a hack.

I will have a look at your latest proposals for a fix.

Best,

Vincnt

--
All messages to this mailing list should adhere to the Code of Conduct: https://lyrasis.org/code-of-conduct/
---
You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/5pXe65VY0IU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/f2cd4e9a-9b11-4355-9890-75a70f8aa484n%40googlegroups.com.