Serve an Esri Web AppBuilder web app from HTTP

How to serve an Esri Web AppBuilder web app from HTTP

When an Esri Web AppBuilder web app is configured with a portalUrl value served from HTTPS, the web app automatically redirects users to HTTPS when visited via HTTP. While this is best-practice in production, it can be a burden in development when you want to quickly run a local version of the web app. Below is a quick script written with Python standard libraries to serve a web app over HTTP. It works by serving a config.json that is modified to use HTTP rather than HTTPS. This allows you to keep config.json using the HTTPS configuration for production but serve the web app via HTTP during development.

The script should be saved alongside the config.json in the root of the web app. I would recommend running chmod a+x runserver to enable you to execute the server directly via ./runserver. Alternatively, you could install this somewhere on your system path to invoke from any directory (something like cp runserver /usr/local/bin/serve-esri-app for a unix-based system).


Hosting Jupyter at a subdomain via Cloudflare

Full Disclosure: I am NOT an expert at Jupyter or Anaconda (which I am using in this project), there may be some bad habits below...

Below is a quick scratchpad of the steps I took to serve Jupyter from a subdomain. Jupyter is running behind NGINX on an OpenStack Ubuntu instance and the domain's DNS is set up to use Cloudflare to provides convenient SSL support. I was suprised by the lack of documentation for this process, prompting me to document my steps taken here.

Cloudflare

  1. Set up Cloudflare account, utilizing its provided Name Servers with my domain registration.
  2. Set up Cloudflare DNS Record for subdomain (ex jupyter to server from jupyter.mydomain.com). In the image below, the DNS entry for the Jupyter server was "greyed-out", relegating it to "DNS Only" rather than "DNS and HTTP Proxy (CDN)".. Now that Cloudflare supports websockets, this is no longer necessary and you're able to take advantage of using Cloudflare as a CDN (admittedly, I'm not sure how useful this actually is, but it's worth mentioning). Setting up DNS Record
  3. Ensure Crypto settings are set correctly. You should probably be using Full SSL (Strict) rather than Flexible SSL as shown in the image below, however that is outside the scope of this post. SSL Settings Auto-rewrite to HTTPS

Install Anaconda

Follow instructions described here.

Set up an Upstart script

On the server, you'll want Jupyter to start running as soon as the server starts. We'll use an Upstart script to acheive this.

# /etc/init/ipython-notebook.conf
start on filesystem or runlevel [2345]
stop on shutdown

# Restart the process if it dies with a signal
# or exit code not given by the 'normal exit' stanza.
respawn

# Give up if restart occurs 10 times in 90 seconds.
respawn limit 10 90

description "Jupyter / IPython Notebook Upstart script"
setuid "MY_USER"
setgid "MY_USER"
chdir "/home/MY_USER/notebooks"

script
    exec /home/MY_USER/.anaconda3/bin/jupyter notebook --config='/home/MY_USER/.jupyter/jupyter_notebook_config.py'
end script

Configure Jupyter

Populate Jupyter with required configuration. You should probably auto-generate the configuration first and then just change the applicable variables.

# .jupyter/jupyter_notebook_config.py
c.NotebookApp.allow_origin = 'https://jupyter.mydomain.com'
c.NotebookApp.notebook_dir = '/home/MY_USER/notebooks'
c.NotebookApp.open_browser = False
c.NotebookApp.password = 'some_password_hash'
c.NotebookApp.port = 8888
c.NotebookApp.kernel_spec_manager_class = "nb_conda_kernels.CondaKernelSpecManager"
c.NotebookApp.nbserver_extensions = {
  "nb_conda": True,
  "nb_anacondacloud": True,
  "nbpresent": True
}

Wire Jupyter up with Nginx

To be able to access Jupyter at port 80, we'll need to reverse proxy to the service. Nginx can take care of this for us. Jupyter uses websockets to stream data to the client, so some

# /etc/nginx/sites-enabled/jupyter.conf
# Based on example: https://gist.github.com/cboettig/8643341bd3c93b62b5c2
upstream jupyter {
    server 127.0.0.1:8888 fail_timeout=0;
}

 map $http_upgrade $connection_upgrade {
     default upgrade;
     '' close;
 }

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    # Make site accessible from http://localhost/
    server_name localhost;

    client_max_body_size 50M;

    location / {
        proxy_pass http://jupyter;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location ~* /(api/kernels/[^/]+/(channels|iopub|shell|stdin)|terminals/websocket)/? {
        proxy_pass http://jupyter;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # WebSocket support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }
}

Django Admin Fu, part 2

Continuing with the Django Admin Fu post part 1.

Action with Intermediate Page

Sometimes you may need an admin action that, when submitted, takes the user to a form where they provides some additional detail. The docs mention a bit about providing intermediate pages, but not a lot. It states:

Generally, something like [writing a intermediate page through the admin] isn’t considered a great idea. Most of the time, the best practice will be to return an HttpResponseRedirect and redirect the user to a view you’ve written, passing the list of selected objects in the GET query string. This allows you to provide complex interaction logic on the intermediary pages.

I do see where the docs are coming from and it would probably be easier to do as advised, but I think there could be something said about keeping all admin logic within the admin page. Doing something like the following would take the user to an intermediate form.


Django Admin Fu, part 1

I've been putting some time into building out the Django Admin site for one of my company's projects. Here are some notes I've taken about straying away from the beaten path. I find surprisingly little information about how to do these things on StackOverflow or elsewhere. These were put used when working with Django 1.6.7.

Fake The Model, Make The View

You may want a form on the Django Admin that exists along side the model views but doesn't actually represent a model. This strays somewhat from what the Django Admin is set up to do (some on the #django channel on Freenode have stated that the admin should only be for CRUD operations on Django models.) None-the-less, if you do want to inject a form into the admin along side your models, this is a method that worked for me.

It revolves around generating a fake model that you register to your app's admin view. After that, you create a model admin that inherits from the standard ModelAdmin.

See more in part 2.