Blank screen with nginx reverse proxy #64

fnberta · 2016-03-05T20:08:45Z

I'm accessing nginx on my server via an SSL connection and passing the request to the dashboard express app via a reverse proxy. The title of the tab gets named "Parse Dashboard" but the screen is completely blank.

My dashboard config is:

{
  "apps": [
    {
      "serverURL": "https://SERVER_IP/api/data",
      "appId": "XXXXX",
      "masterKey": "XXXX",
      "appName": "APPNAME"
    }
  ],
  "users": [
    {
      "user":"user1",
      "pass":"XXXXX"
    },
    {
      "user":"user2",
      "pass":"XXXXX"
    }
  ]
}

And the nginx proxy config is:

location /dashboard {
        proxy_pass http://127.0.0.1:4040;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection 'upgrade';
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;
    }

I'm using a similar configuration for the express app that runs parse-server and that works flawlessly. Any idea what could be going wrong here? If I run the dashboard locally it works perfectly fine.

The text was updated successfully, but these errors were encountered:

drew-gross · 2016-03-06T02:27:27Z

Could you check if your server is responding with the correct files? The dashboard only makes about 5 requests the dashboard app. Also, the dashboard requires the connection to the dashboard be HTTPS (to prevent accidental leakage of the master keys) which may be causing issues. (although I would expect an error message in that case, not a blank page)

Cliffordwh · 2016-03-06T09:18:37Z

Identical problem my side. Have HTTPS server and still blank. Title tho says "Parse Dashboard"

fnberta · 2016-03-06T11:10:46Z

A GET request to https://SERVER_IP/dasboard returns:

<!DOCTYPE html>
<html>
    <title>Parse Dashboard</title>
    <body>
        <div id="browser_mount"></div>
        <script src="/bundles/dashboard.bundle.js"></script>

    </body>
</html>

Which is correct I guess? But /bundles/dashboard.bundle.js is not correctly served because /bundles is not piped to the express app but instead handled by nginx, which of course cannot find the file. Changing the path in the index.html to:

/dashboard/bundles/dashboard.bundle.js

and changing my nginx setup, so that /dashboard is piped through to the express app as /:

location /dashboard/ {
    proxy_pass http://127.0.0.1:4040/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
}

results in the dasboard trying to load but failing with a "404, Oh no, we can't find that page!" error. So it seems like the /dashboard prefix would be needed for other files as well. Can I set this somewhere "globally"?

Btw, if I pipe / to the express app, the dashboard works perfectly. But this of course conflicts with other content I would like to serve on /.

drew-gross · 2016-03-06T19:11:36Z

the 404 is because there is no /dashboard route. The routes are the same as on dashboard.parse.com. Try /apps.

Cliffordwh · 2016-03-09T14:59:39Z

@fnberta You manage to find a fix for this?

guitcastro · 2016-03-09T22:22:05Z

I am also having this issue as well in the Heroku.

gfosco · 2016-03-09T23:38:50Z

I think we can address this. The dashboard is using / to start its paths, so it can only currently be hosted on the root of a URL. Will work on a PR to use relative paths.

vegidio · 2016-03-10T04:53:33Z

+1

felipeandradebezerra · 2016-03-10T14:56:15Z

Same issue on an EC2 nano instance and OS X El Capitan 10.11.3 both running Node.js 4.3.2

fnberta · 2016-03-10T19:29:08Z

@Cliffordwh No, for the moment I am directly accessing the Express app via SSL. But looking forward to switch back to the reverse proxy when the relative paths land!

peterdotjs · 2016-03-11T16:05:36Z

@andremilk for your local issue - can you post more info in #120?

Cliffordwh · 2016-03-17T14:27:43Z

any news on this? or fix to get parse-dashboard to run off a sub? and not the root /

thanks

joeyslack · 2016-03-17T18:44:12Z

Hey there,

It's an issue with npm instal --production. Unfortunately, this app has not been tested with production flag, so your app will not work without some changes.

You'll want to modify the .gitignore file, and remove the following:

bundles/
PIG/bundles/
Parse-Dashboard/public/bundles/
Parse-Dashboard/parse-dashboard-config.json

Then, when you run: npm install on your dev, check in the files it generates to your local repo, then deploy those files to your production.

drew-gross · 2016-03-17T18:50:39Z

@joeyslack the --production flag is left over from our internal build process for running dashboard.parse.com. For just using the dashboard, I recommend installing from npm. For developing the dashboard, I recommend cloning the repo and using npm run dashboard.

joeyslack · 2016-03-17T19:46:51Z

Cool thanks. I'll send a PR then with recommendations for deploys working
with hosting (AWS)
On Thu, Mar 17, 2016 at 11:50 AM Drew [email protected] wrote:

@joeyslack https://github.com/joeyslack the --production flag is left
over from our internal build process for running dashboard.parse.com. For
just using the dashboard, I recommend installing from npm. For developing
the dashboard, I recommend cloning the repo and using npm run dashboard.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#64 (comment)

Cliffordwh · 2016-03-18T05:48:06Z

I don't see this solving the issue. All the files are there on the NPM run, just can not run via a sub directory only on root domain ( / ). We need relative paths or set a prefix globally for the path.

joeyslack · 2016-03-18T17:38:18Z

@Cliffordwh I'm personally missing files on npm run, after a npm install --production, you have a /bundles folder after doing that?

devgeek27 · 2016-03-23T03:51:42Z

Blank screen with Parse Dashboard title issue is happening to me as well. I have deployed Dashboard to Elastic Beanstalk and having the blank screen there. The Dashboard works locally though. The problem is with loading <script src="/bundles/dashboard.bundle.js"></script> file. Does anyone know how to fix that?

Cliffordwh · 2016-03-23T13:35:33Z

@gfosco any luck on this to allow relative paths?

joeyslack · 2016-03-23T17:00:26Z

Hey guys, read my comment above on how to fix it for remote hosts (like elastic beanstalk).

You'll want to first run npm install locally, and then modify your .gitignore file, to remove the /bundles (and other) paths. No idea why someone would ever check in those gitignore changes.

Then, when you do your commit and deploy, the bundle will be available.

Secondarily, if you are using AWS Beanstalk, you'll have to set up a static path for /bundle -> to point to the /public folder.

I offered to send a PR but apparently it's not wanted?

devgeek27 · 2016-03-23T20:21:48Z

@joeyslack Thanks mate. It did the job. Now I have it up and running with EB.

CiraciNicolo · 2016-04-05T16:27:19Z

+1

drew-gross · 2016-04-05T23:41:22Z

This should be fixed now.

thuantran · 2016-04-06T07:34:05Z

I ran an npm update to update to 1.0.8 but it still doesn't work for me behind nginx.
Here's my config.json:

{
  "apps": [
    {
      "allowInsecureHTTP": 1,
      "serverURL": "url",
      "appId": "appid",
      "masterKey": "masterkey",
      "appName": "appname"
    }
  ],
  "users": [
    {
      "user": "user",
      "pass": "pass"
    }
  ]
}

And here's my nginx config

location /admin/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://localhost:4040/;
    proxy_ssl_session_reuse off;
    proxy_set_header Host $http_host;
    proxy_redirect off;
  }

I also get 404 on /bundles/dashboard.bundle.js resource.

The nginx virtual server config also has HTTPS termination as it is also the reverse proxy for parse-server and that's working. What's wrong? If you need other information, please do tell.

Best regards,
Thuan

vegidio · 2016-04-06T07:59:29Z

I'm also having the same problem described by @thuantran

drew-gross · 2016-04-06T18:06:26Z

I'm actually not particularly familiar with nginx. @gfosco might be able to help more, or you could ask a question on Stack Overflow or Server Fault. I do know that the relative paths issue originally brought up has been fixed, so it sounds like you might be seeing a different issue.

vegidio · 2016-04-06T18:26:12Z

Hi,

Basically what I want to do is to have Parse Server accessible through the URL: my-parse-domain.com, but when the user type my-parse-domain.com/dashboard it will show the Parse Dashboard. Sadly it's not working yet (I installed the latest version 5 minutes ago) and I used the same nginx configuration used by @thuantran.

The problem is: when I access my-parse-domain-com/dashboard it's still showing a blank screen. I looked at the page source code and I found this:

<!DOCTYPE html>
<html>
  <title>Parse Dashboard</title>
  <body>
    <div id="browser_mount"></div>
    <script src="/bundles/dashboard.bundle.js"></script>
  </body>
</html>

The script tag is starting with a slash "/". It means that it will look for the file /bundles/dashboard.bundle.js in the domain root (my-parse-domain-com/bundles/dashboard.bundle.js), but this is wrong, it's getting a 404 error.

The correct behavior is to have script tag start without "/", like this bundles/dashboard.bundle.js so the Parse Dashboard will look for the dashboard.bundle.js file in the relative location. In my case: my-parse-domain-com/dashboard/bundles/dashboard.bundle.js

I hope this helped to clarify the problem :)

Thanks.

thuantran · 2016-04-07T01:55:23Z

Finally manage to fix it, by running the dashboard at root and removing "try_files $uri $uri/ =404;" in location /.

In any case the problem with running under relative path like /admin/ on mine previous or any other like @vegidio previously still causing the problem like him stated.

cyring · 2016-04-09T09:32:27Z

So far, this is how I have successfully made it work with an EC2 box (amazon Linux distrib.)

Browser (https) <---> NginX (proxy) <---> parse(dashboard) <---> parse(server) <---> MongoDB (database)

MongoDB:
1- start | restart the Mongo daemon
sudo service mongod restart

Parse-Server :
2- start the server in background
( nohup parse-server --appId "<YOUR APP ID>" --masterKey "<YOUR MASTER KEY> --publicServerURL https://your.server.com/parse" > parse.log ) &

Parse-Dashboard :
3- apply the last commit to allow the --mountPath option in index.js
4- provide a parse-dashboard-config.json such as :

{
  "apps": [
    {
      "serverURL": "https://your.server.com/parse",
      "appId": "<YOUR APP ID>",
      "masterKey": "<YOUR MASTER KEY>",
      "appName": "Your app name"
    }
  ],
  "users": [
    {
      "user":"<some>",
      "pass":"<some>"
    }
  ]
}

5- start the dashboard server in background :
( nohup parse-dashboard --config parse-dashboard-config.json --mountPath /board > board.log ) &

NginX :
6- update the /etc/nginx/nginx.conf as bellow

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;
    include /etc/nginx/conf.d/*.conf;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 2048;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    server {
        listen                  80;
        listen                  [::]:80 default_server ipv6only=on;
        return                  301 https://$host$request_uri;
    }

    server {
        listen                  443;
        server_name             your.server.com;

        ssl                     on;
        ssl_certificate_key     /etc/pki/nginx/your.server.com.key;
        ssl_certificate         /etc/pki/nginx/your.server.com.crt;
        ssl_protocols           TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers             'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:AES256+ECDHE';

        root                    /usr/share/nginx/html;
        index                   index.html index.htm;

        location /board/ {
                proxy_pass http://localhost:4040/board/;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
        }

        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://localhost:1337/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_redirect off;
        }
    }
}

7- start | restart the NginX service
sudo service nginx restart

8- optionally, trace your log files
sudo tail -f /var/log/nginx/error.log -f /var/log/nginx/access.log -f /var/log/mongodb/mongod.log -f $HOME/parse.log -f $HOME/board.log

wassup- · 2016-12-26T11:16:18Z

For people here who've (like me) tried all of the above but are still getting served a blank page (title but no content): please check the page's sourcecode to make sure it's not empty.

If it's not empty, follow the link to the included javascript login.bundle.js or dashboard.bundle.js file. If your browser gives you a 404 (file not found), make sure NginX's sendfile is off. Apparently this is important when NginX is acting as a reverse proxy.

This solved it for me, YMMV. More info about sendfile here: https://t37.net/optimisations-nginx-bien-comprendre-sendfile-tcp-nodelay-et-tcp-nopush.html

viktorlott · 2019-03-15T14:00:57Z

Umm.. Had the same issue when i tried to access my dashboard with https://xxxxx.com/dashboard. Used nginx proxy_pass (https to http), and got the blank screen but with net::ERR_CONTENT_LENGTH_MISMATCH in console.
Strange part was that it worked when i tried to access it locally. (https://localhost/dashboard)

Looked around a bit and found that
NGINX needs to run as a user that have permission to static files. (caching them or something, idk)
So i tried to run sudo nginx and it worked. (but dont run sudo in production)

other solution -
adding this to nginx.conf

user nobody;

Add support to new back4app-dashboard server settings

shodanx2 · 2022-11-06T07:43:52Z

Hi,

This issue is google top link for "nginx redirect just black screen"

And to anyone that ends up here, what you most likely need to do is just
change your http redirection code

vferdiansyah mentioned this issue Mar 11, 2016

ERROR in ./dashboard/index.js and blank page #120

Closed

drew-gross added the in-progress label Mar 15, 2016

drew-gross assigned gfosco Mar 15, 2016

drew-gross closed this as completed Apr 5, 2016

cyring mentioned this issue Apr 25, 2016

IOS SSL Problem OSX/iOS parse-community/parse-server#937

Closed

lacker unassigned gfosco Apr 5, 2017

douglasmuraoka pushed a commit that referenced this issue Nov 29, 2019

Merge pull request #64 from back4app/new-back4app-dashboard

359b520

Add support to new back4app-dashboard server settings

snyk-bot mentioned this issue Jul 19, 2022

refactor: upgrade otpauth from 7.1.3 to 8.0.1 #2219

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Blank screen with nginx reverse proxy #64

Blank screen with nginx reverse proxy #64

fnberta commented Mar 5, 2016

drew-gross commented Mar 6, 2016

Cliffordwh commented Mar 6, 2016

fnberta commented Mar 6, 2016

drew-gross commented Mar 6, 2016

Cliffordwh commented Mar 9, 2016

guitcastro commented Mar 9, 2016

gfosco commented Mar 9, 2016

vegidio commented Mar 10, 2016

felipeandradebezerra commented Mar 10, 2016

fnberta commented Mar 10, 2016

peterdotjs commented Mar 11, 2016

Cliffordwh commented Mar 17, 2016

joeyslack commented Mar 17, 2016

drew-gross commented Mar 17, 2016

joeyslack commented Mar 17, 2016

Cliffordwh commented Mar 18, 2016

joeyslack commented Mar 18, 2016

devgeek27 commented Mar 23, 2016

Cliffordwh commented Mar 23, 2016

joeyslack commented Mar 23, 2016

devgeek27 commented Mar 23, 2016

CiraciNicolo commented Apr 5, 2016

drew-gross commented Apr 5, 2016

thuantran commented Apr 6, 2016

vegidio commented Apr 6, 2016

drew-gross commented Apr 6, 2016

vegidio commented Apr 6, 2016

thuantran commented Apr 7, 2016

cyring commented Apr 9, 2016

wassup- commented Dec 26, 2016

viktorlott commented Mar 15, 2019

shodanx2 commented Nov 6, 2022

Blank screen with nginx reverse proxy #64

Blank screen with nginx reverse proxy #64

Comments

fnberta commented Mar 5, 2016

drew-gross commented Mar 6, 2016

Cliffordwh commented Mar 6, 2016

fnberta commented Mar 6, 2016

drew-gross commented Mar 6, 2016

Cliffordwh commented Mar 9, 2016

guitcastro commented Mar 9, 2016

gfosco commented Mar 9, 2016

vegidio commented Mar 10, 2016

felipeandradebezerra commented Mar 10, 2016

fnberta commented Mar 10, 2016

peterdotjs commented Mar 11, 2016

Cliffordwh commented Mar 17, 2016

joeyslack commented Mar 17, 2016

drew-gross commented Mar 17, 2016

joeyslack commented Mar 17, 2016

Cliffordwh commented Mar 18, 2016

joeyslack commented Mar 18, 2016

devgeek27 commented Mar 23, 2016

Cliffordwh commented Mar 23, 2016

joeyslack commented Mar 23, 2016

devgeek27 commented Mar 23, 2016

CiraciNicolo commented Apr 5, 2016

drew-gross commented Apr 5, 2016

thuantran commented Apr 6, 2016

vegidio commented Apr 6, 2016

drew-gross commented Apr 6, 2016

vegidio commented Apr 6, 2016

thuantran commented Apr 7, 2016

cyring commented Apr 9, 2016

wassup- commented Dec 26, 2016

viktorlott commented Mar 15, 2019

shodanx2 commented Nov 6, 2022