Is it possible to change the hostname for generated URLs when using RAW mode?

52 views
Skip to first unread message

Michel Albert

unread,
Mar 27, 2014, 5:40:36 AM3/27/14
to pl...@googlegroups.com
Generally, I ssh into a remote box to do development. In that case, I run the app server and plovr on there. A problem on that box is that the company firewall only allows SSH and HTTP connections to that machine. Plovr runs on a separate port however, and, when using RAW mode, it tries to load source files from

    http://<remote-hostname>:<remote-port>/...

In my case this won't work as <remote-port> is being blocked. And if I set up port-forwarding using SSH, I would need to access the resources as:

    http://localhost:<forwarded-port>/...

So my question is: is it possible to control the URLs which are generated by plovr? Currently I am helping myself by running a browser on the remote box using X11 forwarding. But that's fairly cumbersome :\

Michel Albert

unread,
Mar 27, 2014, 5:43:17 AM3/27/14
to pl...@googlegroups.com
Ah... forgot to mention that I looked into https://code.google.com/p/plovr/source/browse/src/org/plovr/cli/ServeCommandOptions.java
and could not find something helpful :(

Ilia Mirkin

unread,
Mar 27, 2014, 11:59:18 AM3/27/14
to pl...@googlegroups.com
I think if you forward enough ports it should all be fine. Presumably
you have some webserver, on, say, remote:8000, and plovr running on
remote:9812. So if you were sitting at remote locally, you'd go to
localhost:8000 and all would be well. But you can also just forward
both 8000 and 9812, and go to localhost:8000 on the "local" machine
(i.e. the one you're ssh'ing from), and it should similarly work just
as well.

Is there some additional complication that causes this to not work?
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "plovr" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to plovr+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Michel Albert

unread,
Mar 29, 2014, 6:54:01 AM3/29/14
to pl...@googlegroups.com, imi...@alum.mit.edu
Disclaimer: I just tested this here at home and the links generated by plovr are just fine. I will have to double-check what exactly was going on at the office. But I am fairly certain the symptoms were as explained. Maybe an old version of plovr? I'll check that on Monday.


The problem is that I use plovr  in RAW mode and it generates script tags loading the sources from "remote-ip:9810" instead of "localhost:9810".

Here's an example I have in my template:

    <script type="text/javascript" src="http://{{request.host.split(':')[0]}}:9810/compile?id=dev&amp;mode=raw"></script>

This is rendered as:

    <script type="text/javascript" src="http://localhost:9810/compile?id=dev&amp;mode=raw"></script>

This one request works fine, but the raw mode generates and injects tags like the following:

    <script type="text/javascript" src="http://displacer:9810/input/dev/closure/goog/base.js"></script>

In the generated link, the hostname is no longer "localhost". As it now tries to connect to that host directly it won't pass through the firewall.

Ilia Mirkin

unread,
Mar 29, 2014, 10:52:05 AM3/29/14
to pl...@googlegroups.com
https://github.com/bolinfest/plovr/blob/master/src/org/plovr/CompilationServer.java#L175

This code has been there ~forever... it _should_ just parrot the
referer, and override the port with the port. So make sure that the
forwarded port is the same as the local one.

Hmm, it would have made a lot more sense for it to just use the same
as what was in the Host header, I wonder why we didn't do that...
Michael, do you happen to remember?

Michael Bolin

unread,
Apr 1, 2014, 8:37:42 PM4/1/14
to pl...@googlegroups.com
Ilia: I think it's because I was just being dumb. I can't think of a good reason to prefer referer over host.

Michel Albert

unread,
Apr 8, 2014, 8:21:20 AM4/8/14
to pl...@googlegroups.com
Sorry for the late reply. I was away the last few days.

I tested it at home and it worked out-of-the-box. But I was careless. The application I tested at home was a Flask application, while the one at work is a legacy PHP application. That application is an ancient app which is not following a sane development process yet and the situation is as follows:

 * The devs connect remote to a dev machine to work on the code.
 * There is a DNS entry for this dev box. So while working on the code, the application is accessed via this address (due to virtual hosting).
 * A while back, JS has been ported to closure, and the existing process was to compile the code on the dev machine. And not using the "serve" subcommand of plovr.
 * Only ports 22 and 80 are open to the dev machine.

Being able to use "serve" in RAW mode is one of the many baby-steps I am taking to get the development process a bit more convenient.

Now, let's say, the DNS entry is "http://myapp-dev.localdomain.com", then, if I access this in the browser, it will pass the firewall as it is a connection on port 80. However, now plovr (running in RAW mode) will create a bunch of script tags using "http://myapp-dev.localdomain.com:9810/..." as source. This will not pass the firewall anymore.

I'm not sure how to fix this in plovr as, in a way it is related to the development process of this particular app. But it effectively prevents us from using "RAW" mode. The best solution I came up with would still be to add a command-line flag to be able to control the hostname  when creating "script" tags in RAW mode. Or is there another solution?
Reply all
Reply to author
Forward
0 new messages