enable local development #13
Conversation
- enables local development over http
- don't get the nowcast from the database as it's not used anyway - the nowcast should be taken from the epidata api, rather than reading from the database directly
- include in header as this will be used across several pages in the near future - remove outdated local copy of the library - use hosted version as this will always be up-to-date with the epidata api
- remove the registration - remove the worker's source code - remove the deployment - add code to unregister the worker, which is **persistent** in the browser - write some commentary on the situation
- removes final dependency on the epidata database, at least for "normal-season" epicast - populate "latest issue" async in javascript in the places it's needed (it's only needed for dislpay purposes)
- update the list of required fields to reflect that some preferences are currently disabled - fixes the bug where advanced preferences can't be updated
- css was interpreted as php in the past, but no longer - removed the old css file - removed the htaccess file which made this hack possible
- grants access to the development vesion of the site from the private 127.16.0.0/12 subnet - used to allow unfettered access during local development in a docker environment - fix typo
- include table definitions, along with brief commentary - include a minimally functional set of development data - create the docker images needed for local development, along with documentation and required files - full local development guide to come in follow-up commit
|
Whoa, nice! Looks good to me 👍 |
| AuthType Basic | ||
| AuthName "Restricted Site: Crowdcast" | ||
| AuthBasicProvider file | ||
| AuthUserFile /var/www/passwords | ||
| Require user cctest | ||
| ## Resrtict access to known users ## | ||
| Require ip 172.16.0.0/12 |
There was a problem hiding this comment.
Is this supposed to be 127.16.0.0/12?
There was a problem hiding this comment.
thanks for taking a close look! that's a great question.
172 is correct in this case (but wow that is similar to 127...)
172.16.0.0/12 is one of the private IPv4 address ranges, which happens to be the range that Docker uses for internal networking.
The idea here is that we either want a valid user or someone connecting from a local private network, particularly Docker's network.
There was a problem hiding this comment.
Ah -- the commit message says 127. probably muscle memory :)
There was a problem hiding this comment.
oof, definitely muscle memory. glad i typo'd the commit message and not the htaccess file 😄
| ``` | ||
|
|
||
| You should be able to login and interact with the website (e.g. submitting | ||
| predictions) by visiting `http://localhost:10080/` in a web browser. |
There was a problem hiding this comment.
Is there a way to make this work for a pandemic setup where, e.g., my development machine is on campus and I'm shelling into it from home? Are we talking X forwarding or is there a way to expose this address outside localhost?
There was a problem hiding this comment.
oh interesting, that's a good use-case. no need to X-forward. you should be able to use a reverse ssh tunnel to forward localhost:10080 on your at-home machine to localhost:10080 on your at-work machine.
from your at-home machine, this command should work:
ssh -N -L localhost:10080:localhost:10080 your-username@at-work-machine
This works by listening on port 10080 at-home and tunneling connections to port 10080 at-work. (The first localhost:10080 is where to listen at-home, the second localhost:10080 is where to connect at-work.)
This is probably something that should go in the guide. Do you mind letting me know if this works for you?
edit: fix terrible typo, this should be a forward tunnel, not reverse
There was a problem hiding this comment.
(and to be clear, after the ssh command above, you can then open http://localhost:10080/ on your at-home machine, and you should see your "local" (at-work) instance of the website.)
There was a problem hiding this comment.
I have the db and web server running in docker on my work machine, and I can load the site in lynx from there. Alas, the ssh tunnel fails:
$ ssh -N -R localhost:10080:localhost:10080 <me>@<work>
<me>@<work>'s password:
Warning: remote port forwarding failed for listen port 10080
^C$ ssh -N -R 127.0.0.1:10080:127.0.0.1:10080 <me>@<work>
<me>@<work>'s password:
Warning: remote port forwarding failed for listen port 10080
--which seems weird; I'm not a tunneling pro but I've done something like this before. I'll have more time to debug tomorrow morning.
There was a problem hiding this comment.
ahh my bad. this should be a forward tunnel, not reverse. just need to swap out -R with -L as in:
ssh -N -L 127.0.0.1:10080:127.0.0.1:10080 your-username@at-work-machine
(replaced localhost with 127.0.0.1 to be extra safe)
see constituent commits for detailed changelogs. overall this pull request does the cleanup, organization, and docker groundwork needed for local development.
a corresponding local development guide will follow shortly.