Django-polaris

The major feature, multisigature distribution accounts for anchored assets, has a new documentation section explaining how to use the functionality outlined here.

Note: A v1.1.1 release will be pushed when the Stellar Python SDK has Protocol 14 support.

**Features**

- Multi-signature Asset Distribution Account Support
- Up until now, distribution accounts for anchored assets needed to have a single master signer
- Now, anchors can improve the security of the account that controls outbound payments

- Interactive JWTs are now One-Time-Tokens (OTTs)
- Previously, they were short-lived (expired quickly), but they could be used more than once within that timeframe
- Now, `token`s included in the interactive URLs can only be used to open a popup once

- View/Modify Protected Distribution Account Seeds in the Django Admin Panel
- Due to the secret nature of distribution account seeds (Stellar secret keys), they were previously hidden
- Now, if you have the user permissions to edit assets, you can update the distribution seed in the Admin Panel

**Database Migrations**

Multi-signature asset support required a handful of new columns to be added between the two `Transaction` and `Asset models.

New `Transaction` Columns:

- `envelope_xdr` (TextField) (nullable)
- The envelopes submitted to the network are now saved, regardless of simple/multisig account configurations
- `pending_signatures` (Boolean) (default: `False`)
- A `True/False` value indicating if the anchor is internally waiting for signatures to be collected for the transaction
- `channel_seed` (TextField) (nullable)
- The secret key for the channel account created to use as the source account on the multisig transaction

New `Asset` Columns:

These fields are automatically managed by Polaris, no need to populate them yourself. Every time Polaris starts up, it will ping Horizon for the following values:

- `distribution_account_signers` (TextField) (nullable)
- The JSON-serialized `signers` object returned from a request to Horizon's `/accounts/<distribution account public key>`
- `distribution_account_thresholds` (TextField) (nullable)
- The JSON-serialized `thresholds` object returned from a request to Horizon's `/accounts/<distribution account public key>`
- `distribution_account_master_signer` (TextField) (nullable)
- If the distribution account has a master signer, it will be fetched and saved here on application startup.

This is a patch release for a bug discovered in 1.0.

**Bug Fixes**

- The URLs used to render the withdraw page template were deposit URLs if the data submitted was invalid.
- This fix ensures the URLs rendered are always for the appropriate transaction type

**Features**

- A `testnet` command was added to make issuing assets and testnet resets easier
- Polaris now fully supports logging via the `logging` standard python package
- `PolarisSameSiteMiddleware` is no longer required for SEP-24 anchors
- All environment variables can be listed in settings.py by prepending the variable name with 'POLARIS_'
- This strategy comes with security concerns. Ensure your secrets are never checked into source control
- SEP-12 `PUT /customer` requests can use the `id` parameter as recently added to the SEP

**Breaking Changes**

- All polaris-specific variables defined in `settings.py` must now be prepended with 'POLARIS_'
- This applies to `ACTIVE_SEPS` and `ENV_PATH`
- As well as any environment variables specified within the `settings.py` file
- The scripts integration function must now return a list of `TemplateScript` objects
- `TemplateScript` objects contain a JS source file path and other meta data
- The SEP-12 `.delete()` integration function now must raise the Django exception `ObjectDoesNotExist` for 404 HTTP responses
- This exception replaces `ValueError`
- SEP-31 `GET /customer` was updated to include a 404 response
- Polaris' `.get()` integration function should raise `ObjectDoesNotExist` for 404, `ValueError` for 400

**Database Changes**

There are no schema changes from 0.13.2 to 1.0. However, 1.0 squashes all migrations files generated prior to this release. Make sure to update your database's `django_migrations` table by deleting all migrations after `0001_initial` where `app='polaris'`. This will ensure the eventual second migration will be applied properly.

Includes migrations, bug fixes, and a previously-missing feature.

**Features**
- SEP-24 has an optional `amount` parameter that can be specified in `POST /transactions/interactive/deposit` API calls. Polaris now supports this parameter.
- Previously wallets would have to append the `amount` field to the provided interactive URL.

**Migrations**
- Increases the maximum character limit for `Transaction.status` from 30 to 31.
- `pending_transaction_info_update` is 31 characters, so if this status were assigned it would raise an error, effectively blocking transaction info updates.
- Removes the default value for `Asset.code` and makes the column nullable

**Bug Fixes**
- The first migration mentioned above
- When information submitted in forms is invalid, the evaluated form is not re-rendered in the template. Now, forms are re-rendered as expected
- This bug was introduced with the `form_for_transaction()` integration function.

This patch release fixes a major SEP-31 bug released in versions 0.12 and 0.13.

SEP-31's old `pending_info_update` status was split into two new statuses [here](https://github.com/stellar/stellar-protocol/pull/660):
- `pending_transaction_info_update`
- `pending_customer_info_update`

However, Polaris continued to use `pending_info_update`. This makes SEP-31 Polaris anchors almost unusable by clients because they would have to watch for the old status and check both the SEP-12 `GET /customer` endpoint and the `GET /transaction` to determine what type of update is necessary. Developers using Polaris would also have to intentionally use the old status to remain consist with Polaris' behavior.

This release removes `pending_info_update` as a valid status and adds the `pending_transaction_info_update` and `pending_customer_info_update` statuses.

This release also corrects a small bug in the `/transactions` endpoint schema.
- `Transaction.required_info_update` --> `Transaction.required_info_updates`

Releases 0.12 and 0.13 will be removed from PyPi in the near future to prevent unassuming users from running a faulty SEP-31 service.

This release contains many breaking changes, all in preparation for 1.0.

**DB Changes**
- `Asset.withdraw_anchor_account` and `sender_anchor_account` have been merged into `receiving_anchor_account`
- `Transaction.deposit_memo`, `withdraw_memo`, and `send_memo` have been merged into `memo`
- `Transaction.deposit_memo_type`, `withdraw_memo_type`, and `send_memo_type` have been merged into `memo_type`
- `Asset.send_fee_percent` and `send_fee_fixed` were given defaults of 0 instead of being nullable

**Breaking Changes**

General:
- Some keyword arguments for `register_integrations()` have been changed
- `toml_func` --> `toml`
- `fee_func` --> `fee`
- `scripts_func` --> `scripts`,
- `info` --> `sep6_info`
- `send` --> `sep31_receiver`
- `Transaction.amount_fee` must be calculated by the anchor from ``poll_pending_deposits()`` or ``execute_outgoing_transactions()``
- Polaris will still attempt to calculate `Transaction.amount_fee` if there is no registered `fee` function
- `PROJECT_ROOT` is no longer used from `settings.py`. Polaris will now use `BASE_DIR` by default and `ENV_PATH` if specified.

SEP 6 & 24:
- `content_for_transaction()` has been replaced by two functions
- `form_for_transaction()`: returns the next form to be served to the user during the interactive flow
- `content_for_template()`: returns a dictionary containing customizable attributes for the template to be rendered to the user
- This was implemented so `content_for_template()` could be called for requests to Polaris `transaction/more_info` endpoint
- Added `icon_path` field to the list of allowed keys-value pairs returned from `content_for_template()`
- If not present, Polaris will try to use the `ORG_LOGO` URL returned from the anchor's registered `toml` function
- This replaces the need to create a `company_icon.svg` file
- `process_sep6_request()` is now passed an unsaved `Transaction` object representing the transaction to be created
- the transaction passed should only be saved if the request is valid

SEP31:
- The SEP-31 API itself was changed. See the [changes](https://github.com/stellar/stellar-protocol/compare/c53ea43..98fd80f) to understand why some of the following Polaris changes were made
- `SendIntegration` has been renamed to `SEP31ReceiverIntegration` following related changes to the SEP
- `process_send_request()` --> `process_post_request()`
- `process_update_request()` --> `process_patch_request()`
- `process_post_request()` is now passed an unsaved `Transaction` object instead of the transaction ID
- This mirrors the solution implemented for `process_sep6_request()`

**Bug Fixes**
- Added SEP-31 transactions query for most-recently completed transactions (used in `watch_transactions`)
- SEP-10 no longer attempts to decode request bodies manually (this was a problem when using `charset` in request headers)
- Polaris no longer uses hard-coded XDR error strings to detect errors when making SEP-24 deposits
- Polaris now uses the correct fee columns on the `Transaction` when users don't calculate the fee themselves