Allow different configuration and serving ports (to allow for nginx + ssl) #48

New Issue

2013-11-07T15:45:59Z

dlikhten commented

2013-11-07 15:45:59 +00:00

(Migrated from github.com)

So I want to run SSL in development. This poses a challenge because an SSL-enabled page will not accept non-ssl javascript.

So naturally rack-livereload needs to run in ssl mode. But of course I don't expect you guys to write an SSL server. So NGINX to the rescue!!!

If you were to let me specify a port, say 1234, but the server runs on a different port, say 4567, I can have my nginx redirect port 1234 (in ssl) to talk to non-ssl port 4567. And thus I can have ssl in my development environment and still get live reloading.

So I want to run SSL in development. This poses a challenge because an SSL-enabled page will not accept non-ssl javascript. So naturally rack-livereload needs to run in ssl mode. But of course I don't expect you guys to write an SSL server. So NGINX to the rescue!!! If you were to let me specify a port, say 1234, but the server runs on a different port, say 4567, I can have my nginx redirect port 1234 (in ssl) to talk to non-ssl port 4567. And thus I can have ssl in my development environment and still get live reloading.

johnbintz commented

2013-11-07 18:51:02 +00:00

(Migrated from github.com)

So the issue is that you're loading pages on localhost:4567, but because of the proxying, localhost:1234 is being used for urls to the LiveReload JS? Try setting the :host option in the middleware configuration to localhost:4567 to override the automatic detection. Since using this through a proxy is such an edge case, I'll only add code to detect and use that if someone else provides it, but I think hard-coding :host will do it for now.

So the issue is that you're loading pages on localhost:4567, but because of the proxying, localhost:1234 is being used for urls to the LiveReload JS? Try setting the `:host` option in the middleware configuration to `localhost:4567` to override the automatic detection. Since using this through a proxy is such an edge case, I'll only add code to detect and use that if someone else provides it, but I think hard-coding `:host` will do it for now.

dlikhten commented

2013-11-07 19:27:31 +00:00

(Migrated from github.com)

@johnbintz so if I can get my websockets to listen on port [default] but then the js get rendered/requests sent to my overridden port, then this solves the problem as it becomes just an nginx config issue.

johnbintz commented

2013-11-07 21:16:18 +00:00

(Migrated from github.com)

Does WebSockets need to go through SSL too for this to work? I have very little experience with SSL interactions, beyond setting up with Apache to serve using it.

dlikhten commented

2013-11-07 21:26:45 +00:00

(Migrated from github.com)

Once you are on a ssl-enabled page, the browser is VERY unhappy with insecure content. It will refuse to communicate via ajax to non-ssl enabled endpoints. Not 100% sure about websockets but I believe it is subject to the same restrictions.

So point is all I need is the enabling functionality (ability to poke one port, but serve on another port). I think this can be overridden in the page by overriding that global constant that rack injects, so the JS thinks one port is being used, and nginx can do all the ssl work for you, meanwhile the server is being really ignorant of all this and just listening for non-ssl.

Once you are on a ssl-enabled page, the browser is VERY unhappy with insecure content. It will refuse to communicate via ajax to non-ssl enabled endpoints. Not 100% sure about websockets but I believe it is subject to the same restrictions. So point is all I need is the enabling functionality (ability to poke one port, but serve on another port). I think this can be overridden in the page by overriding that global constant that rack injects, so the JS thinks one port is being used, and nginx can do all the ssl work for you, meanwhile the server is being really ignorant of all this and just listening for non-ssl.

johnbintz commented

2013-11-07 21:48:22 +00:00

(Migrated from github.com)

Then, if I understand correctly, I would try changing both :host and :live_reload_port to the host:port nginx is serving from and the port through which nginx will proxy WebSockets to an SSL version, respectively. I can try setting up a similar setup tomorrow if that doesn't work and play with it myself to figure it out.

Then, if I understand correctly, I would try changing both `:host` and `:live_reload_port` to the host:port nginx is serving from and the port through which nginx will proxy WebSockets to an SSL version, respectively. I can try setting up a similar setup tomorrow if that doesn't work and play with it myself to figure it out.

mattscilipoti commented

2014-07-10 16:25:34 +00:00

(Migrated from github.com)

Any word on this? I'm having similar issues.

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: github-migration/rack-livereload#48