Developers using the Mobile App Builder have recently had problems testing their apps from the MAB because the login from the app fails. This is a problem when using a new version of Google Chrome (version 38), but the underlying problem applies to other browsers either now or possibly in the future. If this is happening to you, read on!

The problem ha to do with loading “mixed content” or “insecure content”. The Mobile App Builder Web site uses SSL and therefore the MAB and your app front end are loaded into your browser using HTTPS. However, during development, people often use a Mobile Web application that uses only HTTP (when you create a Mobile Web application in Progress Developer Studio for OpenEdge (PDSOE), the service that you create uses HTTP). So when you’re in the MAB and run a test, the app’s UI, scripts, etc., are loaded via HTTPS and then the app makes requests (including login) to your service that using HTTP. This is an example of "mixed content" (secure HTTPS resources using the insecure HTTP protocol to load additional resources). By default, current browsers will at least issue a warning about this (the warning may be visible only if you are running the debug tools in the browser). Chrome used to just issue a warning, but with the recent update it blocks the HTTP content. The first request that gets blocked this way is your login attempt. (Firefox enforces this same restriction by the way. And since this is a security issue, we should expect browsers that don’t currently block mixed content to do so in the future.)

What can you do about this? First, be aware that this is mainly a problem during development. The deployed production version of your back end Mobile Web application should use HTTPS, which would eliminate the problem. If there is some good reason that your back end doesn’t use HTTPS, probably your front end doesn’t need to either.

Second, while you’re developing, there are a couple of options for telling Chrome to go ahead and load the mixed content anyway. There’s a relatively safe way and a less safe, but more convenient, way. The safe way is to attempt your login as usual, note that it will fail, but then also note that Chrome displays a small shield at the right end of the address bar when it blocks the content.

If you click on the shield, Chrome gives you the option to reload the page, including the insecure content (you would click on “Load unsafe script” in the picture below):

If you click on the “Learn more” link, it will take you to a page with an explanation of how Chrome handles insecure content. For convenience, here is that link:

That help page includes a discussion of the second, less safe, way of overriding Chrome’s mixed content blocking. There is a startup option you can use if you run Chrome from a command line that will direct Chrome to always load insecure content. You can also add the option to a Windows shortcut. This is much more convenient than having to click on the little shield every time you run your app, but the key word here is ALWAYS – as long as you have Chrome running after you start it with the option, it will automatically load insecure content, regardless of what Web site you may go to. If you add it to a Windows shortcut, every time you start Chrome from that shortcut, regardless of where you go, Chrome won’t block insecure content.

Another possibility is to test your app from PDSOE instead of from the MAB, but I have not verified that as a workaround yet.