cf355a6fee
* s/AccessKeyDataLimit/DefaultDataLimit/g for shadowbox * Implement per-key custom data limits in shadowbox * Shadowbox integration test * Fix the manager service test to maintain backwards compatibility with the GET /server response * Fix integration test for Travis * Fix lint errors * Implement removal of access key data limits * Persist custom data limits * Bump Shadowbox version number * Add a per key dat alimit count to the feature metrics endpoint This also involved modifying the schema of uproxysite:uproxy_metrics_dev.feature_metrics to include the new field. See https://cloud.google.com/bigquery/docs/managing-table-schemas#bq_1 for how this was accomplished Tested: yarn do metrics_server/test && yarn do metrics_server/test_integration * Collect usage metrics for per-key data limits * API documentation and cleanup * Respond to review comments * Respond to review comments * Don't encode the data limit in the access key url This should have been caught in the integration test, but the integration test was miswritten with "echo" instead of "fail", cause the test to mistakenly pass. Fixing this exposed other errors in the test, which were fixed. The test has been confirmed to both pass and fail successfully. * Fix the manager service unit test * Remove stray files * Split integration test into individual functions * Clarify comment in the AccessKey interface * Be more explicit about behavior when no data limits are set * Remove spuriosu import added by vscode * DOn't bump shadowbox version number yet * Rename to accessKeyToApiJson * Don't export AccessKeyJson and use "StorageJson" * Don't await data limit enforcement * Rename the defaultDataLimit getter * Make dataLimit in the accesskey model readonly * Use nullish coalescing operator |
||
|---|---|---|
| scripts | ||
| src | ||
| third_party | ||
| .clang-format | ||
| .dockerignore | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| jasmine.json | ||
| LICENSE | ||
| macos-signing-certificate.p12.enc | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tslint.json | ||
| yarn.lock | ||
Outline Server
This repository has all the code needed to create and manage Outline servers on DigitalOcean. An Outline server runs instances of Shadowsocks proxies and provides an API used by the Outline Manager application.
Go to https://getoutline.org for ready-to-use versions of the software.
Components
The system comprises the following components:
-
Outline Server: a proxy server that runs a Shadowsocks instance for each access key and a REST API to manage the access keys. The Outline Server runs in a Docker container in the host machine.
See
src/shadowbox -
Outline Manager: an Electron application that can create Outline Servers on the cloud and talks to their access key management API to manage who has access to the server.
-
Metrics Server: a REST service that the Outline Server talks to if the user opts-in to anonymous metrics sharing.
Code Prerequisites
In order to build and run the code, you need the following installed:
Then you need to install all the NPM package dependencies:
yarn
Note: If you are using root (not recommended on your dev machine, maybe in a container), you need to add { "allow_root": true } to your /root/.bowerrc file.
This project uses Yarn workspaces.
Build System
We have a very simple build system based on package.json scripts that are called using yarn
and a thin wrapper for what we call build "actions".
We've defined a do package.json script that takes an action parameter:
yarn do $ACTION
This command will define a do_action() function and call ${ACTION}_action.sh, which must exist.
The called action script can use do_action to call its dependencies. The $ACTION parameter is
always resolved from the project root, regardless of the caller location.
The idea of do_action is to keep the build logic next to where the relevant code is.
It also defines two environmental variables:
- ROOT_DIR: the root directory of the project, as an absolute path.
- BUILD_DIR: where the build output should go, as an absolute path.
Build output
Building creates the following directories under build/:
web_app/: The Manager web app.static/: The standalone web app static files. This is what one deploys to a web server or runs with Electron.
electron_app/: The launcher desktop Electron appstatic/: The Manager Electron app to run with the electron command-linebundled/: The Electron app bundled to run standalone on each platformpackaged/: The Electron app bundles packaged as single files for distribution
invite_page: the Invite Pagestatic: The standalone static files to be deployed
shadowbox: The Proxy Server
The directories have subdirectories for intermediate output:
ts/: Autogenerated Typescript filesjs/: The output from compiling Typescript codebrowserified/: The output of browserifying the JavaScript code
To clean up:
yarn run clean