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

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

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

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

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

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

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

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

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

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

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

Any update for 2.8 timeline?

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

Any update for 2.8 timeline?

+1

^ +1

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

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

+1

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

Any status update on this important topic?

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 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.

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

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

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

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

I guess #9277 is a duplicate also

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

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)

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.

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)

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:// ?

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?

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

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?

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.

Super Dev Mode seems to work only on localhost, but not on IP address of the machine which makes it not discoverable in the same network. I need it to run on the IP address so that other devices can talk to it. I also tried to set up the apache server, but I am not familiar with apache server configs file. Therefore, couldn't get it working from your guide. It would have been great if you could explain the details on the Apache server config file. My Spring Boot server runs on port 8090. Can you please help me building the Apache Server config file based on that?

Especially with the howto of vasvir I was able to get our GWT applications running at SuperDevMode!

One remark/topic which maybe related to GWT Version 2.8.2:
I had the problem that code lines in the source maps didn't fit after I redefined the CrossSiteIframeLinker.
This was the case for http as well as for https.
After a longer trial and error I found out that CrossSiteIframeLinker uses the annotation @Shardable which is NOT inherited. After defining the sub type HttpsCrossSiteIframeLinker with this annotation the code lines fit and break points work.

I have no glue about the relations, but the effect may be important for other users as well ...

So I've been struggling with this same issue, but have discovered a pretty straight-forward solution that works well for me that I wanted to share. This essentially makes use of the gwt code server, but without involving the bookmarklet.

First, fire up the gwt code server like normal:

$ mvn gwt:run-codeserver

This will bring up a webserver on the local machine, where the compiled code will be served from:
http://localhost:9876/

However, the compilation doesn't happen unless it gets triggered by an http request, but this can be done manually by hitting this URL:
http://localhost:9876/recompile/Adminui?mgwt.density=mid&mgwt.formfactor=desktop&user.agent=safari

You can now access the compiled assets from the local webserver. In my case the URL was:
http://localhost:9876/Adminui/Adminui.nocache.js

The trick now is to get the browser to use the gwt assets served from the local webserver instead of the production webserver. This is where the Requestly Chrome extension comes in (https://www.requestly.in/).

Using Requestly, I created a "Redirect Request Rule", and set it up with the following settings:
When Request [Url] [Matches (Wildcard)]: https://testmachine.development.lab:2443/adminui/Adminui/*
Destination Url: http://localhost:9876/Adminui/$1

This means I can now open up the application page running on a production server, and requests for things like:
https://testmachine.development.lab:2443/adminui/Adminui/Adminui.nocache.js
Get redirected to: http://localhost:9876/Adminui/Adminui.nocache.js

You'll be able to open Chrome Developer Tools on the Network tab and see the requests get redirected with 307's.

Again, you still have to trigger the code to compile manually, but I've set up my IDE so whenever I make changes and save a file, it will ping this URL and trigger the recompile:
http://localhost:9876/recompile/Adminui?mgwt.density=mid&mgwt.formfactor=desktop&user.agent=safari

I disable the HTTPS vs HTTP checks in chrome by using the following command line option:
`google-chrome http://your-url --allow-running-insecure-content

@jalbr74 . Thanks for sharing! But I have got a question.
How do you debug the actual code in Chrome? I was not able to see the java files in Chrome....

@michelcouto I didn't really do anything special to enable source maps, but I seem to have no problems opening and debugging the source code in Chrome. I assume source maps get included automatically when you run "mvn gwt:run-codeserver".

Running like this, I'm able to bring up Chrome Dev Tools, and go to the "Sources" tab, use Ctrl+P to open a file, and type the name of the Java file I want to open. Then I'm able to set and hit the desired breakpoints in the Java code.

Here's the configuration I'm using for the gwt-maven-plugin, but like I said, I don't think I did anything special to enable source maps:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>gwt-maven-plugin</artifactId>
    <version>${gwt.version}</version>
    <configuration>
        <strict>true</strict>
        <testTimeOut>180</testTimeOut>
        <mode>htmlunit</mode>
        <includes>**/*GwtTest.java</includes>
        <style>OBF</style>
        <copyWebapp>true</copyWebapp>
        <hostedWebapp>${webappDirectory}</hostedWebapp>
        <runTarget>index.html</runTarget>
        <module>${gwt.module}</module>
        <draftCompile>${gwt.draftCompile}</draftCompile>
    </configuration>
    <executions>
        <execution>
            <id>compile</id>
            <goals>
                <goal>compile</goal>
                <goal>test</goal>
            </goals>
            <configuration>
                <logLevel>ERROR</logLevel>
            </configuration>
        </execution>
        <execution>
            <id>codeserver</id>
            <goals>
                <goal>run-codeserver</goal>
            </goals>
            <configuration>
                <logLevel>INFO</logLevel>
            </configuration>
        </execution>
    </executions>
</plugin>