JHipster behind reverse proxy

Overview of the issue

The UI doesn’t display anything when it’s loaded behind a reverse proxy on my remote server (no other port than port 80 opened so I use a proxy_pass with nginx). It’s perfectly reachable but it seems that webpack-angular 2 has some trouble with the path http://my-domain/my-path

vendor.dll.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.manifest.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.global.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.main.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.polyfills.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.main.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found) c9977571b3904794d148.global.bundle.js Failed to load resource: the server responded with a status of 404 (Not Found)

Motivation for or Use Case

This is a recurrent problem I encounter every time I run it behind a reverse proxy. Unfortunately, I couldn’t find any solution or documentation on the topic.

It seems that the /*.bundle.js are retrieved from http://my-domain/*.bundle.js instead of http://my-domain/my-path/*.bundle.js

Reproduce the error

Just add a: location /my-path/ { proxy_pass: localhost:port; } in the nginx configuration file (here using Ubuntu 16.04 )

Related issues

No solution or similar issue found; no documentation at all.

Suggest a Fix

My current investigation lead me to webpack.dev.js where there might be configurations for the proxy though I couldn’t point the real issue or the configuration to make.

JHipster Version(s)

JHipster Generator v4.1.1

JHipster configuration

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "*",
      "nativeLanguage": "en"
    },
    "jhipsterVersion": "4.1.1",
    "baseName": "*",
    "packageName": "*",
    "packageFolder": "*",
    "serverPort": "8080",
    "authenticationType": "jwt",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Disk",
    "prodDatabaseType": "mysql",
    "searchEngine": "elasticsearch",
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "jwtSecretKey": "*",
    "clientFramework": "angular2",
    "useSass": false,
    "clientPackageManager": "yarn",
    "applicationType": "monolith",
    "testFrameworks": [],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "en",
    "languages": [
      "en",
      "zh-tw",
      "nl",
      "fr",
      "ko",
      "mr"
    ]
  }
}

Entity configuration(s) entityName.json files generated in the .jhipster directory

The problem is not related to any entity

Browsers and Operating System

java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
git version 2.7.4
node: v7.8.0
npm: 4.4.4
bower: 1.8.0
gulp:
[11:12:52] CLI version 3.9.1
yeoman: 1.8.5
yarn: 0.21.3
Docker version 17.03.1-ce, build c6d412e
docker-compose version 1.11.2, build dfed245

• Checking this box is mandatory (this is just to show you read everything)

[pascalgrimaud]

@ruddell : using ./ instead of / in the index.html seems to be the right solution. I’ve just made some very very fast tests and it works. But there are some error logs in browser when I navigate in different page:

• change in index.html: ./
• add in spring boot config: server.contextPath: /toto
• go to http://localhost:8080/toto

For me, there is maybe a change to do in index.html and some documentation about it. Thanks @ruddell and don’t worry it’s not urgent 😃

[ruddell]

@pascalgrimaud Maybe changing it to ./ would pick up the correct base when it is not /? I’m not sure if it even works for this issue but I think I remember helping someone with this when deploying to a Tomcat context path.

I’m traveling this weekend so I don’t have time to test right now