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).
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.
Set up Cloudflare account, utilizing its provided Name Servers with my domain registration.
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).
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.
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.
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.