Improve local development/testing configuration

[dleehr]

While local django accounts can be used for authentication, transferring projects expects to authenticate with DukeDS by providing an OAuth token.

We should include a mechanism to use the D4S2 application without a running DukeDS instance or OAuth service

[dleehr]

Documenting my current approach for testing interactively (cc @johnbradley):

1. Configure an OAuthService (using real values)
2. Put 127.0.0.1 d4s2.gcb.duke.edu in my local /etc/hosts file
3. Run d4s2 locally with sudo python manage.py runsslserver 443

Now, when I visit https://d4s2.gcb.duke.edu, I'm actually connecting to the locally running instance. It does use a self-signed certificate, but otherwise it works.

[dleehr]

It does use a self-signed certificate

For this to work with DukeDSClient, I added verify=False to a the requests calls.

Has to be a better way 😄

[dleehr]

Some thoughts/ideas:

• The authentication is already fairly well isolated. Since django has a local account system we can relatively easily handle the case when no OAuthServices are configured
• The one part where this breaks down is when we need to make a call to DDS. We assume that we have an OAuth token (or can refresh one), then we send it to DDS for one of their tokens and make more DDS API calls.

So a few ways to address:

• A Mock DDS API server that responds to the few DukeDS endpoints we need for delivery and share (not too many of them - project_transfers, user/project lookup). We'd still have to handle the case that local django users would have no OAuth tokens, but that's an authentication concern. This could be a flask (or similar) standalone script that behaves based on command-line arguments or static JSON data. Would there be value in something like this for DukeDSClient too? I think apiary even does stuff like this, and I'm sure there are plenty of existing software projects.
• a flag in settings.py to change the behavior (e.g. settings.MOCK_DDS_SERVER=True means that we override these behaviors in the code directly. Atmosphere does something like this for mock authentication, but it's really only patching over a couple code paths. We'd essentially need to swap in an entirely different ddsc module, and then we wouldn't be testing how we've integrated the real one.

[dleehr]

Auth has been moved out to a separate app. Perhaps a mock DDS API server is the best thing to have.

[dleehr]

A related trick I use for testing the web service is to log into the DukeDS API explorer and get a token. Then I put that token in the D4S2 django database connected to my user. It's good for a couple hours and doesn't require hosts file forgeries.