New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Super Dev Mode won't work for https pages #7535

Open
dankurka opened this Issue Jun 10, 2015 · 47 comments

Comments

Projects
None yet
@dankurka
Member

dankurka commented Jun 10, 2015

Originally reported on Google Code with ID 7538

Browsers are starting to block mixed-scripting, which is when an https page loads an
http script. Since the Super Dev Mode code server doesn't use https, this means it
won't work for debugging https pages. (I'm told this recently stopped working for Chrome
and read that it's long been true for IE.)

We could add support for https in the code server, but a further problem is getting
a valid certificate, which is often unavailable for developer workstations. (Or perhaps
a self-signed cert is enough? This needs research.)

I'm somewhat inclined to simply not support Super Dev Mode at all for https, because
this would make it safer to enable the dev mode hook by default in all GWT apps. We
could check the URL scheme in the dev mode hook and do nothing, and as a result, the
hook would have no effect on high-security sites, even in older browsers. (Context:
it's generally easier to not have to recompile a GWT app when moving from QA to production,
so a runtime check is better.)

We could also put a suitable UI in the "Dev Mode On" bookmarklet saying that it won't
work on a https page.

(However, perhaps there are people who need to debug https sites?)

Background:
http://www.imperialviolet.org/2012/07/19/hope9talk.html

Reported by skybrian@google.com on 2012-07-19 23:44:00

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I work on a GWT project which has recently received the requirement to use SSL, which
we also need to use on our staging and testing servers. We've just started experimenting
with Super Dev mode, and I suspect it will be particularly useful for debugging issues
on our staging servers (I'll probably stick to traditional dev mode for local development
because it is simply faster.). So at least for us, much of the value of super dev mode
would be dependent on SSL support.

Something which might work, but I haven't yet tried, is to proxy Super Dev Mode through
an SSL-enabled apache server with a reverse proxy.

Reported by Isharainbowlight on 2012-10-23 20:56:11

Member

dankurka commented Jun 10, 2015

I work on a GWT project which has recently received the requirement to use SSL, which
we also need to use on our staging and testing servers. We've just started experimenting
with Super Dev mode, and I suspect it will be particularly useful for debugging issues
on our staging servers (I'll probably stick to traditional dev mode for local development
because it is simply faster.). So at least for us, much of the value of super dev mode
would be dependent on SSL support.

Something which might work, but I haven't yet tried, is to proxy Super Dev Mode through
an SSL-enabled apache server with a reverse proxy.

Reported by Isharainbowlight on 2012-10-23 20:56:11

@dankurka dankurka self-assigned this Jun 10, 2015

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
No real fix but here is a status update:

I did put in the security check to disable https by default, and enabled the codeserver
hook by default.

I've heard that one team made this work. They put a https proxy in front of the code
server.

If you want to try it, you will have to override a method to disable a security check,
in CrossSiteIFrameLinker.getJsDevModeRedirectHookPermitted() [1]. Then load the bookmarks
using the proxy and hopefully all the URL's going back to the code server will start
with https and go through the proxy. This should bypass the browser warning.

[1] https://gwt.googlesource.com/gwt.git/+/master/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java

Reported by bslesinsky on 2014-06-08 17:07:52

Member

dankurka commented Jun 10, 2015

No real fix but here is a status update:

I did put in the security check to disable https by default, and enabled the codeserver
hook by default.

I've heard that one team made this work. They put a https proxy in front of the code
server.

If you want to try it, you will have to override a method to disable a security check,
in CrossSiteIFrameLinker.getJsDevModeRedirectHookPermitted() [1]. Then load the bookmarks
using the proxy and hopefully all the URL's going back to the code server will start
with https and go through the proxy. This should bypass the browser warning.

[1] https://gwt.googlesource.com/gwt.git/+/master/dev/core/src/com/google/gwt/core/linker/CrossSiteIframeLinker.java

Reported by bslesinsky on 2014-06-08 17:07:52

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Judging by https://gwt.googlesource.com/gwt/+/dffcd80ce6ff2b2b515e9372230f9ed58cd6ca90
it shouldn't be that hard to add SSL support to CodeServer.

The bookmarklets would need to be updated to avoid mixed-content and instead display
an error message (i.e. when clicking a bookmarklet for http://localhost:9876 on an
https:// page, it would tell you that you need to update your bookmarklet to use https://
rather than trying to load from http://localhost:9876)

Reported by t.broyer on 2014-06-09 08:59:49

Member

dankurka commented Jun 10, 2015

Judging by https://gwt.googlesource.com/gwt/+/dffcd80ce6ff2b2b515e9372230f9ed58cd6ca90
it shouldn't be that hard to add SSL support to CodeServer.

The bookmarklets would need to be updated to avoid mixed-content and instead display
an error message (i.e. when clicking a bookmarklet for http://localhost:9876 on an
https:// page, it would tell you that you need to update your bookmarklet to use https://
rather than trying to load from http://localhost:9876)

Reported by t.broyer on 2014-06-09 08:59:49

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Hello,
Could you please post instructions on how to setup SuperDevMode for application using
SSL? Unfortunately, our testbed requires https because of an external dependency to
an authentication server. 
I managed to configure a proxy through apache so the code server is available under
https but I keep getting the "This module doesn't have Super Dev Mode enabled" message
when I try to compile the code. If I use a combination of the application on http and
server code on https it works fine but this gives me access only to the public (unsecured)
part of my application.

Reported by dharezlak on 2014-06-12 12:17:03

Member

dankurka commented Jun 10, 2015

Hello,
Could you please post instructions on how to setup SuperDevMode for application using
SSL? Unfortunately, our testbed requires https because of an external dependency to
an authentication server. 
I managed to configure a proxy through apache so the code server is available under
https but I keep getting the "This module doesn't have Super Dev Mode enabled" message
when I try to compile the code. If I use a combination of the application on http and
server code on https it works fine but this gives me access only to the public (unsecured)
part of my application.

Reported by dharezlak on 2014-06-12 12:17:03

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Hi,
we have to use https, too.
That's the only reason why we are still at "normal" DevMode.
Any solution for this problem would be helpful.

Reported by tlang@washtec.de on 2014-06-12 12:51:31

Member

dankurka commented Jun 10, 2015

Hi,
we have to use https, too.
That's the only reason why we are still at "normal" DevMode.
Any solution for this problem would be helpful.

Reported by tlang@washtec.de on 2014-06-12 12:51:31

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Extend CrossSiteIframeLinker and override getJsDevModeRedirectHookPermitted to allow
https; then in your gwt.xml, add:

 <define-linker name="xsiframe" class="path.to.MyCrossSiteIframeLinker" />

Hopefully that should be enough (in addition to setting up a proxy in front of the
codeserver). Note: you need to overwrite the "xsiframe" linker, or you'll have to add
a few other things (<add-linker> and, e.g. AsyncFragmentLoader.LoadingStrategy)

Reported by t.broyer on 2014-06-15 21:19:55

Member

dankurka commented Jun 10, 2015

Extend CrossSiteIframeLinker and override getJsDevModeRedirectHookPermitted to allow
https; then in your gwt.xml, add:

 <define-linker name="xsiframe" class="path.to.MyCrossSiteIframeLinker" />

Hopefully that should be enough (in addition to setting up a proxy in front of the
codeserver). Note: you need to overwrite the "xsiframe" linker, or you'll have to add
a few other things (<add-linker> and, e.g. AsyncFragmentLoader.LoadingStrategy)

Reported by t.broyer on 2014-06-15 21:19:55

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Thanks! That did the trick. I also had to override the devModeUrlWhitelistRegexp property
and include gwt-dev jar for the compilation phase to make it work. Is there a plan
to support code server running through https or is it going to stay on the hack-it-yourself
side?

Reported by dharezlak on 2014-06-16 10:14:28

Member

dankurka commented Jun 10, 2015

Thanks! That did the trick. I also had to override the devModeUrlWhitelistRegexp property
and include gwt-dev jar for the compilation phase to make it work. Is there a plan
to support code server running through https or is it going to stay on the hack-it-yourself
side?

Reported by dharezlak on 2014-06-16 10:14:28

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I have no immediate plan to work on it, but I'll accept patches to make it easier to
set up.

I'm not sure if we can make it work out of the box since installing certificates is
rather tricky. Also, disabling the redirect on https by default is a good safety measure.

It might be possible to do something in cooperation with a Chrome plugin so that developers
can load JavaScript into the web page from localhost without having to set anything
up.

Reported by skybrian@google.com on 2014-06-16 16:53:10

Member

dankurka commented Jun 10, 2015

I have no immediate plan to work on it, but I'll accept patches to make it easier to
set up.

I'm not sure if we can make it work out of the box since installing certificates is
rather tricky. Also, disabling the redirect on https by default is a good safety measure.

It might be possible to do something in cooperation with a Chrome plugin so that developers
can load JavaScript into the web page from localhost without having to set anything
up.

Reported by skybrian@google.com on 2014-06-16 16:53:10

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
I am just wondering if it would be possible to implement a servlet mapped to *.nocache.js
and *.cache.js resources that would be compiling the sources whenever necessary. This
way the code server could be completely omitted. Of course the servlet would be active
only for the development environment. This way http or https schemas would be transparent
for the fetches content. Are there any impediments for such an approach?

Reported by dharezlak on 2014-07-02 07:31:05

Member

dankurka commented Jun 10, 2015

I am just wondering if it would be possible to implement a servlet mapped to *.nocache.js
and *.cache.js resources that would be compiling the sources whenever necessary. This
way the code server could be completely omitted. Of course the servlet would be active
only for the development environment. This way http or https schemas would be transparent
for the fetches content. Are there any impediments for such an approach?

Reported by dharezlak on 2014-07-02 07:31:05

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Update for 2.7
==============

There is no change to https support if you're using the bookmarkets. If you're not
using the bookmarklets, the situation is a bit different.

In 2.7 we support starting Super Dev Mode from Dev Mode, and you can do something similar
using the new -launcherDir flag. In this situation, we're overwriting the nocache.js
with a stub that automatically recompiles if necessary and then loads the new JavaScript.

However, it's doing this by making JSONP requests to the code server, so mixed content
is still an issue. A partial fix would be to also write the .js files to the -launcherDir
target as suggested in #10. Then we wouldn't care whether these files are served over
HTTPS or not. But there is a remaining issue: we still need a way to trigger the recompile
and wait for it to finish. This can't be done by writing static files alone. Perhaps
an extension could do it.

Anyway, there are no plans to implement this for 2.7 since we're past feature freeze.

Reported by skybrian@google.com on 2014-11-04 20:23:27

Member

dankurka commented Jun 10, 2015

Update for 2.7
==============

There is no change to https support if you're using the bookmarkets. If you're not
using the bookmarklets, the situation is a bit different.

In 2.7 we support starting Super Dev Mode from Dev Mode, and you can do something similar
using the new -launcherDir flag. In this situation, we're overwriting the nocache.js
with a stub that automatically recompiles if necessary and then loads the new JavaScript.

However, it's doing this by making JSONP requests to the code server, so mixed content
is still an issue. A partial fix would be to also write the .js files to the -launcherDir
target as suggested in #10. Then we wouldn't care whether these files are served over
HTTPS or not. But there is a remaining issue: we still need a way to trigger the recompile
and wait for it to finish. This can't be done by writing static files alone. Perhaps
an extension could do it.

Anyway, there are no plans to implement this for 2.7 since we're past feature freeze.

Reported by skybrian@google.com on 2014-11-04 20:23:27

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Hi there! I too want to use super-dev mode with https. The problem here is the codeserver
which does not seem to have an option to run in https.

So from what I have read in this thread it seems one needs to setup a reverse proxy
on top of the codeserver to avoid "mixed content" problems on modern browsers?

Is there maybe some easy to understand step-by-step guide for this?

I'm using "Chromium Version 41.0.2272.76 Built on Ubuntu 14.04, running on LinuxMint
17.1 (64-bit)" and although it did not display the super-dev mode correctly out of
the box, after clicking on the silver shield in the right end of the address bar and
click something like 'load anyway' or 'allow' it seems to work now. I do get one line
of warning per resource loaded from the codeserver in the javascript console though.

Reported by kaefert on 2015-03-16 10:07:49

Member

dankurka commented Jun 10, 2015

Hi there! I too want to use super-dev mode with https. The problem here is the codeserver
which does not seem to have an option to run in https.

So from what I have read in this thread it seems one needs to setup a reverse proxy
on top of the codeserver to avoid "mixed content" problems on modern browsers?

Is there maybe some easy to understand step-by-step guide for this?

I'm using "Chromium Version 41.0.2272.76 Built on Ubuntu 14.04, running on LinuxMint
17.1 (64-bit)" and although it did not display the super-dev mode correctly out of
the box, after clicking on the silver shield in the right end of the address bar and
click something like 'load anyway' or 'allow' it seems to work now. I do get one line
of warning per resource loaded from the codeserver in the javascript console though.

Reported by kaefert on 2015-03-16 10:07:49

@dankurka

This comment has been minimized.

Show comment
Hide comment
@dankurka

dankurka Jun 10, 2015

Member
Any update for 2.8 timeline?

Reported by dustin.chesterman on 2015-04-30 18:51:33

Member

dankurka commented Jun 10, 2015

Any update for 2.8 timeline?

Reported by dustin.chesterman on 2015-04-30 18:51:33

@saniaky

This comment has been minimized.

Show comment
Hide comment
@saniaky

saniaky Aug 12, 2015

Any update for 2.8 timeline?

+1

saniaky commented Aug 12, 2015

Any update for 2.8 timeline?

+1

@BenDol

This comment has been minimized.

Show comment
Hide comment

BenDol commented Aug 12, 2015

^ +1

@WTThomas

This comment has been minimized.

Show comment
Hide comment
@WTThomas

WTThomas Aug 12, 2015

+1 👍 , too.
I think this is really important!

+1 👍 , too.
I think this is really important!

@waynerasmuss

This comment has been minimized.

Show comment
Hide comment
@waynerasmuss

waynerasmuss Dec 31, 2015

+1
Working with HTTPS for development makes so many things easier.

+1
Working with HTTPS for development makes so many things easier.

@grabarczyk-t

This comment has been minimized.

Show comment
Hide comment
@grabarczyk-t

grabarczyk-t Feb 25, 2016

Contributor

+1

Contributor

grabarczyk-t commented Feb 25, 2016

+1

@jkocot

This comment has been minimized.

Show comment
Hide comment

jkocot commented Feb 25, 2016

+1

@AlbrechtStriffler

This comment has been minimized.

Show comment
Hide comment

+1

@rlf

This comment has been minimized.

Show comment
Hide comment

rlf commented Apr 8, 2016

+1

@TDesjardins

This comment has been minimized.

Show comment
Hide comment

+1

@jnehlmeier

This comment has been minimized.

Show comment
Hide comment
@jnehlmeier

jnehlmeier Apr 8, 2016

Member

Please stop posting +1 comments. Github now has a reactions button (the smiley icon at each comment) which contains a +1 reaction.

Member

jnehlmeier commented Apr 8, 2016

Please stop posting +1 comments. Github now has a reactions button (the smiley icon at each comment) which contains a +1 reaction.

@WTBenjamin

This comment has been minimized.

Show comment
Hide comment
@WTBenjamin

WTBenjamin Apr 8, 2016

Any status update on this important topic?

Any status update on this important topic?

@dnouls

This comment has been minimized.

Show comment
Hide comment
@dnouls

dnouls Apr 8, 2016

To jnehlmeier ... not sure what all these emoticons are supposed to expres with regards to the issue report or the comments. Is it Thumbs up that there is an issue ? Or Thumbs up to a specific comment about it not being available in an updated release ... etc. I find this very confusing. I miss a voting possibility on bugs to give some indication how many people stumbled on the same issue.

dnouls commented Apr 8, 2016

To jnehlmeier ... not sure what all these emoticons are supposed to expres with regards to the issue report or the comments. Is it Thumbs up that there is an issue ? Or Thumbs up to a specific comment about it not being available in an updated release ... etc. I find this very confusing. I miss a voting possibility on bugs to give some indication how many people stumbled on the same issue.

@jnehlmeier

This comment has been minimized.

Show comment
Hide comment
@jnehlmeier

jnehlmeier Apr 8, 2016

Member

@dnouls If Github does not add a dedicated voting button then adding +1 to the first comment of an issues will probably become the common practice to vote for an issue on Github.

On the issue overview page you can then sort issues based on reactions.

Member

jnehlmeier commented Apr 8, 2016

@dnouls If Github does not add a dedicated voting button then adding +1 to the first comment of an issues will probably become the common practice to vote for an issue on Github.

On the issue overview page you can then sort issues based on reactions.

@WTBenjamin

This comment has been minimized.

Show comment
Hide comment
@WTBenjamin

WTBenjamin Apr 11, 2016

Back to topic:
Any status update on this important topic?

Back to topic:
Any status update on this important topic?

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Apr 12, 2016

Member

Just to make it clear:

  • are you using DevMode, CodeServer with -launcherDir, or CodeServer with (deprecated) bookmarklets?
  • would you be OK with a self-signed certificate for localhost? or would want to provide your own certificate? Or are you only asking for the generated .nocache.js stub to use https:// instead of http:// (and with a different port I believe), and you'd use a reverse-proxy to handle the TLS?

In other words, what kind of setup do people interested in this use? (or would like to use) and what parameters would they like to pass to SDM and how (DevMode is a "command-line proxy" to CodeServer).

Member

tbroyer commented Apr 12, 2016

Just to make it clear:

  • are you using DevMode, CodeServer with -launcherDir, or CodeServer with (deprecated) bookmarklets?
  • would you be OK with a self-signed certificate for localhost? or would want to provide your own certificate? Or are you only asking for the generated .nocache.js stub to use https:// instead of http:// (and with a different port I believe), and you'd use a reverse-proxy to handle the TLS?

In other words, what kind of setup do people interested in this use? (or would like to use) and what parameters would they like to pass to SDM and how (DevMode is a "command-line proxy" to CodeServer).

@kaefert

This comment has been minimized.

Show comment
Hide comment
@kaefert

kaefert Apr 19, 2016

I am using CodeServer with -launcherDir
And to have my https page accept the resources from the CodeServer I have to start my browser with the parameter --allow-running-insecure-content which means I either have to use a seperate browser to debug or I have to compromise on security for all of my browsing...

kaefert commented Apr 19, 2016

I am using CodeServer with -launcherDir
And to have my https page accept the resources from the CodeServer I have to start my browser with the parameter --allow-running-insecure-content which means I either have to use a seperate browser to debug or I have to compromise on security for all of my browsing...

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Apr 19, 2016

Member

@kaefert Could you answer the second question from above?

would you be OK with a self-signed certificate for localhost? or would want to provide your own certificate? Or are you only asking for the generated .nocache.js stub to use https:// instead of http:// (and with a different port I believe), and you'd use a reverse-proxy to handle the TLS?

Also, why do you need TLS? (while using SDM, vs. debugging a compiled version for example)

Member

tbroyer commented Apr 19, 2016

@kaefert Could you answer the second question from above?

would you be OK with a self-signed certificate for localhost? or would want to provide your own certificate? Or are you only asking for the generated .nocache.js stub to use https:// instead of http:// (and with a different port I believe), and you'd use a reverse-proxy to handle the TLS?

Also, why do you need TLS? (while using SDM, vs. debugging a compiled version for example)

@kaefert

This comment has been minimized.

Show comment
Hide comment
@kaefert

kaefert Apr 19, 2016

@tbroyer hmm, well I guess the best implementation would be if I could give the codeserver the path to my java key store file and it's password. But if the browser doesn't mind if the debug tomcat and the codeserver use two different certificates then I wouldn't mind the codeserver generating it's own certificate.

I need https while debugging because I use a singlesignon cookie that I share with other applications that needs to be set with the secure flag.

I guess I could also code around this by disabling the autoredirect from http to https and set the cookie without the secure flag when debugging or when requests come from localhost or something like that, but of course it's always nicer if things just work (TM)

kaefert commented Apr 19, 2016

@tbroyer hmm, well I guess the best implementation would be if I could give the codeserver the path to my java key store file and it's password. But if the browser doesn't mind if the debug tomcat and the codeserver use two different certificates then I wouldn't mind the codeserver generating it's own certificate.

I need https while debugging because I use a singlesignon cookie that I share with other applications that needs to be set with the secure flag.

I guess I could also code around this by disabling the autoredirect from http to https and set the cookie without the secure flag when debugging or when requests come from localhost or something like that, but of course it's always nicer if things just work (TM)

@metteo

This comment has been minimized.

Show comment
Hide comment
@metteo

metteo May 4, 2016

I think this issue is also important in relation to 'Geolocation on secure context only'

There will be more browser apis which will be accessible only using https.

metteo commented May 4, 2016

I think this issue is also important in relation to 'Geolocation on secure context only'

There will be more browser apis which will be accessible only using https.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer May 4, 2016

Member

@metteo Note that localhost is a secure context.

Please answer the above questions to help shape what could/should be done.

Member

tbroyer commented May 4, 2016

@metteo Note that localhost is a secure context.

Please answer the above questions to help shape what could/should be done.

@seamusmac

This comment has been minimized.

Show comment
Hide comment
@seamusmac

seamusmac May 14, 2016

@tbroyer

  1. I am using CodeServer with -launcherDir.
  2. I would be fine with a self signed cert
  3. I wouldn't be against providing my own cert, as I have to setup my local server with a cert for development anyways.
  4. probably just adding a flag, eg sslEnabled to the codeserver would be best,

@tbroyer

  1. I am using CodeServer with -launcherDir.
  2. I would be fine with a self signed cert
  3. I wouldn't be against providing my own cert, as I have to setup my local server with a cert for development anyways.
  4. probably just adding a flag, eg sslEnabled to the codeserver would be best,
@seamusmac

This comment has been minimized.

Show comment
Hide comment
@seamusmac

seamusmac May 14, 2016

I guess #9277 is a duplicate also

I guess #9277 is a duplicate also

@WTBenjamin

This comment has been minimized.

Show comment
Hide comment
@WTBenjamin

WTBenjamin May 17, 2016

@tbroyer

  1. We are using the default parameters:
    -noserver -remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -logLevel INFO -codeServerPort 9997 -war C:\workspace...\war
  2. A self signed cert would be ok
  3. I agree with @seamusmac that providing an own cert would be fine too
  4. @seamusmac +1

@tbroyer

  1. We are using the default parameters:
    -noserver -remoteUI "${gwt_remote_ui_server_port}:${unique_id}" -logLevel INFO -codeServerPort 9997 -war C:\workspace...\war
  2. A self signed cert would be ok
  3. I agree with @seamusmac that providing an own cert would be fine too
  4. @seamusmac +1
@vasvir

This comment has been minimized.

Show comment
Hide comment
@vasvir

vasvir Feb 7, 2017

@tbroyer

  1. I am using SDM with bookmarklet. Please don't deprecate bookmarklets. I believe that -launcherDir configurations do not allow to debug a live website that has deployed a GWT widget. Am I wrong in this assumption?

  2. I have deployed apache in localhost with a self signed certificate in port 9877 that forwards https to http://localhost:9876 I don't have a problem with this setup. I don't mind going the extra mile of setting up a localhost web server in order to get the capability to debug in place.

  3. GWT team could streamline the HTTPS guide below by
    a) allow https by default (step: 4 & 5)
    b) autosense the protocol (http or https) and redirect to the SDM compiler accordingly requiring no manual edit of the bookmarklet (step: 6)

HTTPS setup Guide

The steps required now to do such a setup are:

  1. Install an configure apache: https://wiki.debian.org/Self-Signed_Certificate
    I used the snake oil certificate that comes with debian and accepted the security exception for the browser to trust the server.

  2. Enable proxy modules for apache

  a2enmod proxy
  a2enmod proxy_http
  a2enmod headers 
  1. Use this or something like this for /etc/apache2/sites-enabled/default-ssl.conf
<IfModule mod_ssl.c>
        <VirtualHost *:9877>
                ServerAdmin webmaster@localhost
                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on
                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

                ProxyRequests Off
                SSLProxyEngine On
                <Proxy *>
                        Order deny,allow
                        Allow from all
                </Proxy>
                ProxyPass / http://localhost:9876/
                ProxyPassReverse / http://localhost:9876/
                <Location />
                        ProxyPassReverse /
                        Order deny,allow
                        Allow from all     
                </Location>
                Header edit Location ^http://localhost:9876/ https://localhost:9877/
        </VirtualHost>
</IfModule>
  1. Override the CrossSiteIframeLinker
package com.google.gwt.core.linker;

import com.google.gwt.core.ext.LinkerContext;

public class HttpsCrossSiteIFrameLinker extends CrossSiteIframeLinker {
    @Override
    protected String getJsDevModeRedirectHookPermitted(LinkerContext context) {
        return "$wnd.location.protocol == \"http:\" || $wnd.location.protocol == \"file:\" "
                + "|| $wnd.location.protocol == \"https:\"";
    }
}
  1. Add this to you *.gwt.xml
	<set-configuration-property name="devModeUrlWhitelistRegexp"
		value="http(s)?://(localhost|127\.0\.0\.1)(:\d+)?/.*" />
	<define-linker name="xsiframe"
		class="com.google.gwt.core.linker.HttpsCrossSiteIFrameLinker" />
  1. Edit and change the compile bookmarklet from http://localhost:9876 to https://localhost:9876

  2. Redeploy - and start compiling GWT scripts deployed in https server pages.

vasvir commented Feb 7, 2017

@tbroyer

  1. I am using SDM with bookmarklet. Please don't deprecate bookmarklets. I believe that -launcherDir configurations do not allow to debug a live website that has deployed a GWT widget. Am I wrong in this assumption?

  2. I have deployed apache in localhost with a self signed certificate in port 9877 that forwards https to http://localhost:9876 I don't have a problem with this setup. I don't mind going the extra mile of setting up a localhost web server in order to get the capability to debug in place.

  3. GWT team could streamline the HTTPS guide below by
    a) allow https by default (step: 4 & 5)
    b) autosense the protocol (http or https) and redirect to the SDM compiler accordingly requiring no manual edit of the bookmarklet (step: 6)

HTTPS setup Guide

The steps required now to do such a setup are:

  1. Install an configure apache: https://wiki.debian.org/Self-Signed_Certificate
    I used the snake oil certificate that comes with debian and accepted the security exception for the browser to trust the server.

  2. Enable proxy modules for apache

  a2enmod proxy
  a2enmod proxy_http
  a2enmod headers 
  1. Use this or something like this for /etc/apache2/sites-enabled/default-ssl.conf
<IfModule mod_ssl.c>
        <VirtualHost *:9877>
                ServerAdmin webmaster@localhost
                DocumentRoot /var/www/html

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                SSLEngine on
                SSLCertificateFile      /etc/ssl/certs/ssl-cert-snakeoil.pem
                SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/cgi-bin>
                                SSLOptions +StdEnvVars
                </Directory>

                ProxyRequests Off
                SSLProxyEngine On
                <Proxy *>
                        Order deny,allow
                        Allow from all
                </Proxy>
                ProxyPass / http://localhost:9876/
                ProxyPassReverse / http://localhost:9876/
                <Location />
                        ProxyPassReverse /
                        Order deny,allow
                        Allow from all     
                </Location>
                Header edit Location ^http://localhost:9876/ https://localhost:9877/
        </VirtualHost>
</IfModule>
  1. Override the CrossSiteIframeLinker
package com.google.gwt.core.linker;

import com.google.gwt.core.ext.LinkerContext;

public class HttpsCrossSiteIFrameLinker extends CrossSiteIframeLinker {
    @Override
    protected String getJsDevModeRedirectHookPermitted(LinkerContext context) {
        return "$wnd.location.protocol == \"http:\" || $wnd.location.protocol == \"file:\" "
                + "|| $wnd.location.protocol == \"https:\"";
    }
}
  1. Add this to you *.gwt.xml
	<set-configuration-property name="devModeUrlWhitelistRegexp"
		value="http(s)?://(localhost|127\.0\.0\.1)(:\d+)?/.*" />
	<define-linker name="xsiframe"
		class="com.google.gwt.core.linker.HttpsCrossSiteIFrameLinker" />
  1. Edit and change the compile bookmarklet from http://localhost:9876 to https://localhost:9876

  2. Redeploy - and start compiling GWT scripts deployed in https server pages.

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 7, 2017

Member

FWIW, I proposed https://github.com/tbroyer/gwt-devserver to have the benefits of launcherDir without the constraint of having to somehow deploy it; using a reverse proxy (also proxying the application).

You could also deploy your sourcemaps (possibly to another server) to debug a live server (http://gwtproject.org should work that way)

Member

tbroyer commented Feb 7, 2017

FWIW, I proposed https://github.com/tbroyer/gwt-devserver to have the benefits of launcherDir without the constraint of having to somehow deploy it; using a reverse proxy (also proxying the application).

You could also deploy your sourcemaps (possibly to another server) to debug a live server (http://gwtproject.org should work that way)

@vasvir

This comment has been minimized.

Show comment
Hide comment
@vasvir

vasvir Feb 7, 2017

vasvir commented Feb 7, 2017

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 8, 2017

Member

The primary use case of gwt-devserver is to get the "CodeServer with launcherDir" behavior without the need to write any file to an output directory. This means that:

  • you don't overwrite your "production compiled" nocache.js (this allows easily switching between dev and production mode without the need to recompile, and prevents some cases of broken deployment artifacts where the SDM-generated nocache.js ends up erroneously being deployed to production)
  • you can use your war source directory (e.g. src/main/webapp) without polluting it (for standalone apps, without server side or using APIs on another server through CORS)
  • you don't need to actually deploy the SDM-generated nocache.js (this allows working with remote servers, as is possible with bookmarklets)

The way it works (for the first and third cases above) is by acting as a reverse proxy to your real server (either local or remote), except for yourapp/yourapp.nocache.js which is generated on-the-fly (the same content that CodeServer would write into the launcherDir), and /yourapp/* URLs which are reverse-proxied to the CodeServer (launched as part of the gwt-devserver) so you get up-to-date static assets.
This means that everything is served to your browser by http://localhost:* URLs, and proxied to the appropriate server (local or remote); so it "hides" the HTTPS (browser to gwt-devserver is HTTP, gwt-devserver to your real server can be HTTP or HTTPS); and because localhost is a secure origin you can use all the restricted APIs (geolocation, notifications, etc.) without the need for HTTPS.

This obviously doesn't cover all use cases, but at least covers some of those mentioned above.

Member

tbroyer commented Feb 8, 2017

The primary use case of gwt-devserver is to get the "CodeServer with launcherDir" behavior without the need to write any file to an output directory. This means that:

  • you don't overwrite your "production compiled" nocache.js (this allows easily switching between dev and production mode without the need to recompile, and prevents some cases of broken deployment artifacts where the SDM-generated nocache.js ends up erroneously being deployed to production)
  • you can use your war source directory (e.g. src/main/webapp) without polluting it (for standalone apps, without server side or using APIs on another server through CORS)
  • you don't need to actually deploy the SDM-generated nocache.js (this allows working with remote servers, as is possible with bookmarklets)

The way it works (for the first and third cases above) is by acting as a reverse proxy to your real server (either local or remote), except for yourapp/yourapp.nocache.js which is generated on-the-fly (the same content that CodeServer would write into the launcherDir), and /yourapp/* URLs which are reverse-proxied to the CodeServer (launched as part of the gwt-devserver) so you get up-to-date static assets.
This means that everything is served to your browser by http://localhost:* URLs, and proxied to the appropriate server (local or remote); so it "hides" the HTTPS (browser to gwt-devserver is HTTP, gwt-devserver to your real server can be HTTP or HTTPS); and because localhost is a secure origin you can use all the restricted APIs (geolocation, notifications, etc.) without the need for HTTPS.

This obviously doesn't cover all use cases, but at least covers some of those mentioned above.

@vasvir

This comment has been minimized.

Show comment
Hide comment
@vasvir

vasvir Feb 8, 2017

vasvir commented Feb 8, 2017

@tbroyer

This comment has been minimized.

Show comment
Hide comment
@tbroyer

tbroyer Feb 8, 2017

Member

Hmm, gwt-devserver probably wouldn't work well for that use case.
I'd suggest that in this case you'd probably better debug the real production code using source maps rather than run some dev mode against production (or pre-production) servers. Remember that you can customize the source maps URL (see https://github.com/gwtproject/gwt/blob/2.8.0/user/src/com/google/gwt/core/CrossSiteIframeLinker.gwt.xml#L27-L44) so you can make them point to a server that only you can access (internal server or IP filtering)
That said, if bookmarklets work for you in 2.8, I see no reason to switch (the only issue with bookmarklets IIUC is getting binding properties' values reliably)

Member

tbroyer commented Feb 8, 2017

Hmm, gwt-devserver probably wouldn't work well for that use case.
I'd suggest that in this case you'd probably better debug the real production code using source maps rather than run some dev mode against production (or pre-production) servers. Remember that you can customize the source maps URL (see https://github.com/gwtproject/gwt/blob/2.8.0/user/src/com/google/gwt/core/CrossSiteIframeLinker.gwt.xml#L27-L44) so you can make them point to a server that only you can access (internal server or IP filtering)
That said, if bookmarklets work for you in 2.8, I see no reason to switch (the only issue with bookmarklets IIUC is getting binding properties' values reliably)

@vasvir

This comment has been minimized.

Show comment
Hide comment
@vasvir

vasvir Feb 8, 2017

vasvir commented Feb 8, 2017

@biancashouse

This comment has been minimized.

Show comment
Hide comment
@biancashouse

biancashouse Oct 4, 2017

I have my local appengine working with https by following eric bidelman's nginx guidance, and then subclassing the CrossSiteLinker as you kindly described above. Many thanks for that.

The one remaining issue is that using SDM, whenever you visit the gwt page it auto compilrs, which recreates a new copy of the [module].nocache.js, which always reverts to an address with http.

So a hack is to create a .nocache somewhere that has https and your port number and refer to that file in the .html page that loads the gwt.

The gwt:run maven command picks up a server name and a port from the command-line, but always assumes http, right ?

Question - is there a class we could override where we could generate a .nocache that actually contains https:// ?

I have my local appengine working with https by following eric bidelman's nginx guidance, and then subclassing the CrossSiteLinker as you kindly described above. Many thanks for that.

The one remaining issue is that using SDM, whenever you visit the gwt page it auto compilrs, which recreates a new copy of the [module].nocache.js, which always reverts to an address with http.

So a hack is to create a .nocache somewhere that has https and your port number and refer to that file in the .html page that loads the gwt.

The gwt:run maven command picks up a server name and a port from the command-line, but always assumes http, right ?

Question - is there a class we could override where we could generate a .nocache that actually contains https:// ?

@paulfrench

This comment has been minimized.

Show comment
Hide comment
@paulfrench

paulfrench Oct 18, 2017

Instead of the line....

var serverUrl = 'http://' + hostName + ':<port>';

...being generated in the .nocache.js file can it not just be...

var serverUrl = '//' + hostName + ':<port>';

...so it uses the same protocol as the page it is loaded in?

Instead of the line....

var serverUrl = 'http://' + hostName + ':<port>';

...being generated in the .nocache.js file can it not just be...

var serverUrl = '//' + hostName + ':<port>';

...so it uses the same protocol as the page it is loaded in?

@vasvir

This comment has been minimized.

Show comment
Hide comment
@vasvir

vasvir Oct 18, 2017

vasvir commented Oct 18, 2017

@paulfrench

This comment has been minimized.

Show comment
Hide comment
@paulfrench

paulfrench Oct 18, 2017

Hi Vasvir,
Sorry I was replying in the context of biancashouse comment. I have super dev mode with https and yes I use an apache reverse proxy. We are still using GWT 2.7. The only change I need to make to GWT is copy (from gwt-dev-2.7.0.jar)

com.google.gwt.dev.codeserver/stub.nocache.js

...to my test/src directory in my GWT project and make the amendment to the stub.nocache.js file...

var serverUrl = '//' + hostName + ':__SUPERDEV_PORT__';

I use test/src since it is part of the classpath when working in eclipse and so does not pollute the main code.

Hence if the above change was made, which would still work as before for http, I would not have to make any changes to GWT. But this is only for how we work with GWT in our office internally for development, it might not be sufficient for others. Let me explain.

I've setup a reverse proxy to listen on ports 443 (https) and 9997 (code server port), it simply proxies your requests back to the IP the request came from. For my proxy I've installed our company domain certificates. There is one pre-requisite, the developer must be running their local dev server (not the code server) on port 80.

So get your super dev mode working in http locally by pointing your browser to your local dev server e.g.http://localhost/<module>. For super dev mode in https then just point your browser to https://<reverse-proxy>.<domain>/<module>

The critical parts of the apache httpd-ssl.conf file to get this to work...

Listen 443
Listen 9997
<VirtualHost _default_:443 _default_:9997>
  RewriteEngine On
  RewriteRule ^ - [E=REMOTE_ADDR:%{REMOTE_ADDR}]

  RewriteCond "%{SERVER_PORT}" "443"
  RewriteRule "/(.*)$" "http://%{REMOTE_ADDR}/$1" [L,P]

  RewriteCond "%{SERVER_PORT}" "9997"
  RewriteRule "/(.*)$" "http://%{REMOTE_ADDR}:9997/$1" [L,P]

  ProxyPassInterpolateEnv On
  ProxyPassReverse / http://${REMOTE_ADDR}/ interpolate

The ProxyPassReverse is required for our server side application which issues http redirects. I don't think it is needed for super dev mode.

Cheers

paulfrench commented Oct 18, 2017

Hi Vasvir,
Sorry I was replying in the context of biancashouse comment. I have super dev mode with https and yes I use an apache reverse proxy. We are still using GWT 2.7. The only change I need to make to GWT is copy (from gwt-dev-2.7.0.jar)

com.google.gwt.dev.codeserver/stub.nocache.js

...to my test/src directory in my GWT project and make the amendment to the stub.nocache.js file...

var serverUrl = '//' + hostName + ':__SUPERDEV_PORT__';

I use test/src since it is part of the classpath when working in eclipse and so does not pollute the main code.

Hence if the above change was made, which would still work as before for http, I would not have to make any changes to GWT. But this is only for how we work with GWT in our office internally for development, it might not be sufficient for others. Let me explain.

I've setup a reverse proxy to listen on ports 443 (https) and 9997 (code server port), it simply proxies your requests back to the IP the request came from. For my proxy I've installed our company domain certificates. There is one pre-requisite, the developer must be running their local dev server (not the code server) on port 80.

So get your super dev mode working in http locally by pointing your browser to your local dev server e.g.http://localhost/<module>. For super dev mode in https then just point your browser to https://<reverse-proxy>.<domain>/<module>

The critical parts of the apache httpd-ssl.conf file to get this to work...

Listen 443
Listen 9997
<VirtualHost _default_:443 _default_:9997>
  RewriteEngine On
  RewriteRule ^ - [E=REMOTE_ADDR:%{REMOTE_ADDR}]

  RewriteCond "%{SERVER_PORT}" "443"
  RewriteRule "/(.*)$" "http://%{REMOTE_ADDR}/$1" [L,P]

  RewriteCond "%{SERVER_PORT}" "9997"
  RewriteRule "/(.*)$" "http://%{REMOTE_ADDR}:9997/$1" [L,P]

  ProxyPassInterpolateEnv On
  ProxyPassReverse / http://${REMOTE_ADDR}/ interpolate

The ProxyPassReverse is required for our server side application which issues http redirects. I don't think it is needed for super dev mode.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment