Releases: stellar/django-polaris
v1.2.2
Bug Fix
Introduced in v1.2, watch_transactions
assigned Keypair
objects to Transaction.from_address
when the payment operation did not include a source account. This resulted in a string representation of the Keypair
object being returned from GET /transaction(s)
, instead of the public key string.
This release fixes this bug by ensuring the public key of the Keypair
object is always assigned to Transaction.from_address
.
v1.2.1
The code for this release in in the 1.2.1
branch.
Bug Fix
The SEP-24 /transactions/deposit/interactive/complete
endpoint used when the anchor uses a non-Polaris interactive flow did not have any rest_framework.renderer
classes associated with it, causing requests to this endpoint to fail with a 500 response code. This bug was introduced in v1.2. If you use Polaris' interactive flow (and form integrations), this bug fix does not affect you.
v1.2.0
Features
- Added SEP-24 Claimable Balance Support (protocol change)
- Added
MAX_TRANSACTION_FEE_STROOPS
environment variable- This allows anchors to increase their fee bid in order to minimize chances of
504 Timeout
responses from Horizon
- This allows anchors to increase their fee bid in order to minimize chances of
Database Migrations
- Added
claimable_balance_id
andclaimable_balance_supported
columns to theTransaction
model
Bug Fixes
watch_transactions
detects Path Payment operations (StrictSend & StrictReceive)- In previous versions, only Payment operations were detected
- CORS policy was added to SEP-31 endpoints
- In previous versions, SEP-31 endpoints did not include CORS policy headers in responses
pending_external
deposit transactions are now passed topoll_pending_transactions()
- In previous versions, only transactions that were in
pending_user_transfer_start
were passed
- In previous versions, only transactions that were in
GET /transactions
returns records for assets only enabled for SEP-6- In previous versions, an error response was returned if the requested asset was not also enabled for SEP-24
GET /fee
returns a fee for assets only enabled for SEP-6- In previous versions, an error response was returned if the fee was for an asset that was not also enabled for SEP-24
v1.1.5
Those who run Polaris on a domain different than the domain hosting their SEP-1 stellar.toml must upgrade to this version to be in compliance with SEP-10 v3.0
For example, if you run Polaris on polaris.anchor.com
but your TOML file is hosted at anchor.com/.well-known/stellar.toml
, you must upgrade.
Upgrades Polaris' stellar-sdk
to version 2.10. This version includes support for SEP-10 v3.0.
Adds a SEP10_HOME_DOMAINS
environment variable used in Polaris' SEP-10 authentication. See the Environment Variables documentation for more information.
v1.1.4
Bug Fixes
- Polaris' SEP-6 endpoint removed non-standard fields from the client's
/deposit
request, but SEP-6 allows for custom fields originally described in/info
to be sent as request parameters. This release changes this logic and passes all requests parameters toDepositIntegration.process_sep6_request()
v1.1.3
Bug Fixes
- Polaris can now successfully process received withdrawal transactions with different TX and payment op source accounts
Polaris' watch_transactions
had a faulty assumption that withdrawal transactions sent to the anchor's account would have a payment op source that matches the TX source. This release removes that assumption and always assigns the value of Transaction.from_address
to the payment operation source.
Note: the commit tagged for this release is not accurate, see the v1.1.3 branch for the code/commits.
v1.1.2
Introduces performance improvements, migrations, and bug fixes.
Performance Improvements
Namely, this release improves distribution account loading performance for Assets
by only loading when Asset.distribution_account_*
is accessed instead of on Asset
initialization. Only one Horizon API call will be made per-asset per-process.
DB Migrations
In order to make loading distribution account data more efficient, the following columns were removed from the database and replaced with Asset
object properties:
distribution_account_signers
distribution_account_thresholds
distribution_account_master_signer
This removes an unnecessary DB write operation when an asset's distribution account is loaded from Horizon.
Bug Fixes
- ensures the
amount
key-value pair passed to the registered fee function is aDecimal
instead offloat
v1.1.1
Patch release upgrading Polaris' Stellar SDK to 2.8, which includes support for Protocol 14. Note the SDK has a single breaking change:
- The type of
stellar_sdk.signer.Signer.signer_key
is changed fromXdr.types.SignerKey
tostellar_sdk.signer_key.SignerKey
.
This breaking change did not affect Polaris' use of the SDK, but it may affect your SDK usage.
v1.1.0
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
- A
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>
- The JSON-serialized
distribution_account_thresholds
(TextField) (nullable)- The JSON-serialized
thresholds
object returned from a request to Horizon's/accounts/<distribution account public key>
- The JSON-serialized
distribution_account_master_signer
(TextField) (nullable)- If the distribution account has a master signer, it will be fetched and saved here on application startup.