Super Dev Mode won't work for https pages

[dankurka]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Any update for 2.8 timeline?

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

[saniaky]

Any update for 2.8 timeline?

+1

[BenDol]

^ +1

[WTThomas]

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

[waynerasmuss]

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

[grabarczyk-t]

+1

[jkocot]

+1

[AlbrechtStriffler]

+1

[rlf]

+1

[TDesjardins]

+1

[jnehlmeier]

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

[WTBenjamin]

Any status update on this important topic?

[dnouls]

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]

@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]

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

[rlf]

They did! @jnehlmeier https://github.com/gwtproject/gwt/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

[tbroyer]

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]

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]

@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]

@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]

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]

@metteo Note that localhost is a secure context.

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

[seamusmac]

@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]

I guess #9277 is a duplicate also

[WTBenjamin]

@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]

@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 

3) 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>

4) 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:\"";
    }
}

5) 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" />

6) Edit and change the compile bookmarklet from http://localhost:9876 to https://localhost:9876

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

[tbroyer]

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]

Thomas,

I am sorry I read through gwt-devserver documentation and I failed to grasp it. Don't worry though this is not unusual for me :-)

I don't understand what is the primary use case. If I had to answer at gun point I would say that it is a compatibility bridge to old DevMode (http://localhost:8888) that also somehow covers the SDM case.

I don't understand its usage and its command line arguments. Looks like a wrapper around the existing CodeServer but more complicated. For me CodeServer was also difficult to grasp. I had to follow blindly a StackOverFlow post to set it up and start understanding what's going on.

and finally I can't tell if it can do what bookmarklets currently do and what is the problem with the way the bookmarklets work right now. Sure they feel somewhat hackish but I believe a certain level of setup can be expected from a developer that wants to have instant compile/debug cycle with one click in the browser in situ.

 Vassilis

On Tue, Feb 7, 2017 at 9:35 PM, Thomas Broyer notifications@github.com wrote:

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)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gwtproject/gwt/issues/7535#issuecomment-278115241, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4ROOFIxKZI8VCUFVm1pwKP_KkBwW3Cks5raMdzgaJpZM4FqFj2 .

-- Vassilis Virvilis

[tbroyer]

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]

Thomas,

This is very helpful. Thanks a lot.

I need some time and some rereads to make sure I understand everything.

If I understand correctly the dev-server is in front of everything and proxies to the real servers hence the complexity in the arguments. So if you want to compile/debug something in situ (in the production site) you fire your dev-server with the appropriate arguments (base url to proxy) and point the developer's browser to http://localhost:xxxx - so in theory my use case is covered.

Just to make sure can you please answer one more question: Does that hold true for my use case explained below:

• My GWT script deployed at http[s]://myserver.com/mywidget/
• Client is allowed to use mywidget by enabling CORS at http[s]:// client.com/url <---

With bookmarklets I am able to debug easily mywidget at http://client.com/url but not so easily (without some setup, self signed SSL certificates etc) at https://client.com/url from my local developer machine which doesn't have a public face to Internet. Will your proposed scheme work with this setup?

In any case (either I got it right or not) I believe a schematic drawing with the various use cases would be nice in order to communicate your design more effectively.

Thanks again for your hard effort to educate me.

Vassilis

On Wed, Feb 8, 2017 at 11:55 AM, Thomas Broyer notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gwtproject/gwt/issues/7535#issuecomment-278282380, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4ROHWvizgK0og6GPm7XRR0qoM5_ELkks5raZEPgaJpZM4FqFj2 .

-- Vassilis Virvilis

[tbroyer]

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]

Hmm, I personally don't care much about source maps. Sure it is nice to have but I can work with -preety GWT compiled js.

I don't have a problem sticking with bookmarklets as long the GWT team does not deprecate them completely.

With binding properties do you refer to window.__gwt_bookmarklet_params = {server_url:'https://localhost:9876/',module_name:'mywidget'}; ?

Update: I wrote this mini guide that summarizes the steps required to get https to work with bookmarklets. Here it is https://vasvir.wordpress.com/2017/02/07/gwt-super-dev-mode-https-setup-in-7-steps/

On Wed, Feb 8, 2017 at 6:00 PM, Thomas Broyer notifications@github.com wrote:

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)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gwtproject/gwt/issues/7535#issuecomment-278370005, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4ROJPhxIeQWdqNIDhpBQgDUPsrGCEyks5raeadgaJpZM4FqFj2 .

-- Vassilis Virvilis

[biancashouse]

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]

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]

Hi Paul,

Even if you change the bookmarklet to https the gwt-codeserver still doesn't speak https. So you are going a https server to proxy requests to gwt-codeserver.

There are 7 steps to do this properly. You are jumping to step 6 with this. Please check out my comment in the same issue you posted from or at my blog https://vasvir.wordpress.com/2017/02/07/gwt-super-dev-mode-https-setup-in-7-steps/ which expands a bit.

GWT could eliminate the steps 4-5-6 if they wished.

On Wed, Oct 18, 2017 at 5:14 PM, Paul French notifications@github.com wrote:

Instead of the line....

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

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

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

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gwtproject/gwt/issues/7535#issuecomment-337605408, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4RONJrIMqI4WRWLn8iIiJjvtW-S49Fks5stgfjgaJpZM4FqFj2 .

-- Vassilis Virvilis

[paulfrench]

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

[pedy711]

Hi everyone, can someone please help me? I have a Spring Boot server with SSL enabled on it. I want to use GWT as GUI side of my application. But I get this:

Couldn't load App from Super Dev Mode
server at http://192.168.0.241:9876.
Please make sure this server is ready.
Do you want to try again?

and when I enable "load unsafe script" on Chrome I still get the followings on the console:

Mixed Content: The page at 'https://192.168.0.241:8090/App.html' was loaded over HTTPS, but 
requested an insecure script 'http://192.168.0.241:9876/recompile-requester/App'. This content should 
also be served over HTTPS.

App.nocache.js:54 GET http://192.168.0.241:9876/recompile-requester/App

Can someone please explain in details how I can setup a reverse proxy in front of code server to compile the page just fine?

[pedy711]

For anyone having the same problem. Super dev mode doesn't support SSL. I debug using Super Dev Mode without SSL: mvn gwt:codeserver -Pgwt-prod

To use https, you need to use Production mode. To do so, set to \static folder of Spring Boot Project and then simply package gwt code: mvn package -Pgwt-prod

then just run Spring Boot to serve the static files.

[vasvir]

Also take a look at https://github.com/gwtproject/gwt/issues/7535 for instructions on how to set https in superdev mode

On Mon, Sep 3, 2018 at 4:19 PM pedy711 notifications@github.com wrote:

For anyone having the same problem. Super dev mode doesn't support SSL. I debug using Super Dev Mode without SSL: mvn gwt:codeserver -Pgwt-prod

To use https, you need to use Production mode. To do so, set to \static folder of Spring Boot Project and then simply package gwt code: mvn package -Pgwt-prod

then just run Spring Boot to serve the static files.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/gwtproject/gwt/issues/7535#issuecomment-418113069, or mute the thread https://github.com/notifications/unsubscribe-auth/AD4ROLxP__bBw1REvfjbdeos5j3WCSXXks5uXSxJgaJpZM4FqFj2 .

-- Vassilis Virvilis