handle windows paths better

[wandmagic]

No description provided.

[aj-stein-gsa]

I am cool with this but strongly think we ought to consider: 1) direct POST ... of content via HTTP or 2) access from another HTTP URI after we dive into more secure development considerations. This step brings us farther down the path of madness and assisting LFI attacks. More to come in #18.

[wandmagic]

it might be slightly more difficult for an attacker to make a POST request, but we
I think we certainly should consider

• Sandboxing workspace via configuration
• Encrypting traffic using PGP
• Only allowing connections from localhost

[aj-stein-gsa]

it might be slightly more difficult for an attacker to make a POST request, but we I think we certainly should consider ...

I don't disagree, but we really need to go through a threat model on this, but you should not be exposing the server to the outside world (so it accepts traffic from any interface on the system, not just internal on loopback, explained here if I am not making obvious sense on first pass) and other things should be done if someone chooses to deploy in a "prod-by-default" configuration, which would include an AuthN/AuthZ proxy in front of it and TLS. But you, @david-waltermire, and I and others need to chat through that for a series of pieces one at a time. That is one of the first steps in #18, threat modeling.

I approved the PR as-is for now. The next step is writing down some assumptions so we know what and why we want to do. I am happy with it for now, this is a local development tool. We will evolve to conducive to production deployment as we proceed with 18.