The reference dotplan implementation also exposes these endpoints for account management and authentication. Other implementations may differ and offer other authentication mechanisms (OAuth2 for example, or supporting the creation and invalidation of multiple authentication tokens).
The reference dotplan implementation exposes this endpoint to update a plan using a given authentication token. Other implementations may differ and offer other mechanisms to update a plan (by email or text message for example, or integration with other services).
If experimental features are enabled in this reference implementation, `GET /js/{email}` with an optional `callback` parameter will return a [JSONP](https://en.wikipedia.org/wiki/JSONP) script that calls your function (`handle_dotplan` by default), passing the plan in json format. You can also optionally specify a `pubkey` parameter (if verification fails it will return an `{"error":"..."}` object).
To facilitate service discovery by Dotplan clients and relays, add a [SRV record](https://en.wikipedia.org/wiki/SRV_record) to your email domain with the name `_dotplan._tcp`. For example, to use `dotplan.online` as the service provider for email addresses at `example.com`, the record would look like this:
```
_dotplan._tcp.example.com. 86400 IN SRV 0 1 443 dotplan.online.
Edit the `Dockerfile` if you want to run as a user other than PID 1000, edit the `ENVIRONMENT` section of the `docker-compose.yaml` and make any other customizations for your setup, and edit the example provided `data/msmtprc` with your real SMTP server details (only used to send email verifications for new signups and password reset links).
```
cat schema.sql | sqlite3 data/users.db
docker-compose build
docker-compose up -d
```
You should now be able to make requests at `http://localhost:4227`, which is where you should point your reverse proxy for SSL configuration, etc.
