Currently there's support for only one anchor distribution account, but anchors might have multiple distribution accounts.
The create_stellar_deposit command, for example, should have a parameter for specifying which distribution account to use.

What problem does your feature solve?

Anchors want to be able to have their own HTML, CSS, and JavaScript served in the interactive flow so they can control their brand and UX.

What would you like to see?

A mechanism for anchors to use their own templates for the interactive flow

What alternatives are there?

We plan on providing a "hands-off" approach to the interactive flow where instead of using our Django Form/Template stack, they route the wallet to an external service that serves their own static assets. Template integrations will allow them to control their brand and UX while allowing them to stay within the Polaris framework.

When things go wrong there needs to be an alerting mechanism. We should allow anchors to plug in a webhooks endpoint that we post to on errors or warnings. This should require a design before implementing.

What problem does your feature solve?

Polaris currently does not support true KYC compliance. There is no form to collect the information during the deposit and withdraw flows and no mechanism for developers to store/process the data using Polaris integrations.

What would you like to see?

Added support for building custom KYC flows.

As described in #78 , we want to allow anchors to serve pages during the interactive flow without forms. We'll use this feature to add a "confirm email" step for new users.

Polaris users are identified by an email. If the stellar account passed from the wallet is already associated with an email, KYC has already been collected. If the stellar account is new to the anchor, we'll render the KYC form for the user to fill out.

We want to add several more fields to our deployment's stellar.toml:

• status
• name
• is_asset_anchored
• anchor_asset_type
• anchor_asset

Our current default templates and styles aren't really professional and therefore usable. We can replace them with the UX Vega is pushing. Anchors without frontend teams will likely use these new defaults.

The new JWT model breaks interactive deposit/withdraw after the account did the first transaction. Mostly because of browser caching and lack of re-authentication. Common errors:
403 Session is not authenticated, 403 account for session not found.

If you try to post to the SEP-10 challenge endpoint using application/x-www-form-urlencoded, we try to split the body on the '<' character, but there shouldn't be a '<' character in the body. I think this is a misunderstanding of the sep-10 docs where it says Content-Type: application/x-www-form-urlencoded, body: transaction=<signed XDR (URL-encoded)>) I don' think we actually expect angled brackets there, thats just a signifier that its a token. We should be able to just split the following line on = instead.

https://github.com/stellar/django-polaris/blob/master/polaris/polaris/sep10auth/views.py#L49

Per SEP-24, anchors provide a link in response to /interactive endpoints, which should be the entry-point for the interactive flow. If anchors use Polaris, there is no way to return a link other than for the Polaris-supported interactive endpoint. Anchors should be able to opt out of the interactive flow Polaris supports in favor of their own if they choose.

The change should include an integration point for anchors to provide their own entry-point link for interactive flows. These external interactive flows must end by making a postMessage request back to the parent window, so the wallet can resume control.

SEP1 specifies a NETWORK_PASSPHRASE toml entry to tell clients what network this domain is operating off of. We should add it and make it configurable, at least to testnet/pubnet
https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0001.md#account-information

When a client POSTs to /transaction/withdraw/interactive or /transaction/deposit/interactive it should create a persisted Transaction object to the db. Currently we create an ephemeral UUID, and then upon submission of the interactive webapp we use that UUID to actually create a Transaction object. The problem here is that since there's no record, the /transactions endpoint is empty so it looks like no transaction has been started. It's even more confusing since the transaction originally returned does have an ID so it seems like we should be able to query it, but can't.

When the transaction list is requested, more_info_url comes without parameters.

Our Heroku deployment of the anchor server runs stellar-anchor-server, but we merged that codebase into this repository with #48.

We need to reconfigure Heroku to use docker-compose.prod.yml.

Polaris needs to provide an integration point for anchors to specify the correct information for their toml file.

What version are you using?

v0.9.2

What did you do?

I haven't used polaris yet but I took a look at the SEP-10 implementation here:

What did you expect to see?

I expected to see the address/public-key of the Client's Stellar account set as the sub field of the JWT. The Client's address is the source account of the challenge transaction's first manage data operation.

According to SEP-10's definition of what is in a token the sub field should contain:

the public key of the authenticating Stellar account (G...)

The authenticating Stellar account is the client.

What did you see instead?

The address/public-key of the distribution Stellar account set as the sub field of the JWT.

Currently there is no way for an anchor to display deposit instructions information. In the deposit flow, after entering the amount, we jump straight to the 'receipt' page, and our only deposit steps are our custom 'Admin: Confirm Deposit' button, but real anchors need to be able to show concrete and varied instructions. nTokens deposit screen is shown below.

I think when the Transaction type is deposit and the status is pending_user_transfer_start, we should have more_info_url return a screen similar to below, and create an integration where the anchor can return arbitrary text or html to fit in the gray box with the instructions for how to deposit.

For our staging infrastructure we can move the 'Admin: confirm deposit' button onto this page below the gray box instead of the receipt page.

We added deposit integrations for banking rails in a poll_pending_deposits dameon, removing the need for the /confirm_transaction endpoint. The endpoint should be removed and the call to the endpoint should be removed form the more_info.html file's javascript.

We removed the need to return 403 from /deposit and /withdraw responses in stellar/stellar-protocol#455 since they're the default happy path. We need to change polaris to return 200 instead of 403 when returning the interactive urls.

Developing Polaris should be easy. Right now much of the development process I use has a lot of nuance and tricks.

An ideal dev env would have:

• 5 commands tops to get a fully setup environment
• A local running deployment of the current code
  • this deployment should update whenever code is changed locally

We don't recommend keeping a long-lived jwt in the url of an interactive flow anymore so we should illustrate a best practice for how to return a url with a one-time-token and handle authentication on the backend properly

info here: https://github.com/stellar/stellar-protocol/pull/459/files

SEP-1 and SEP-10 don't provide any details on SIGNING_KEY except that it's private key should be used to sign authentication challenge transactions. @msfeldstein believes the SIGNING_KEY should not be a distribution or issuer account public key. This makes sense because an anchor has one signing key but could anchor multiple assets.

So we'll create a new account on testnet, set the SIGNING_KEY and SIGNING_SEED to the public and private key, respectively.

#48 PR moves stellar-anchor-server code into django-polaris in order to have an easier development setup. Since the same code would be in two places, we decided to retire stellar-anchor-server and deploy the server from this repository instead.

The PR introduces a production deployment setup into django-polaris.

There is potential for loss of precision when using floats. Since we're handling money this is not a good idea, so we'll move to using the DecimalField object in place of FloatField.

According to SEP-24, these field names should be changed in JSON responses for transactions.

The latest code has changed a lot, I think it would be better to synchronize the latest code and then develop it.

Thank you.

Version 0.9.2

Currently the jwt authentication helper validates the jwt as a valid jwt issued by the anchor, but doesn't actually check which user is authenticating. This means anyone can access anyone elses information, such as transaction history, just by authenticating as themself, or any other stellar address.

Endpoints such as /transactions should get the stellar account from the jwt, rather than doing non-standard things like adding an account query parameter to choose who's info to return. /transactions?account=<> is not compliant with the spec and should be removed, using the sub account from the jwt instead.

We should add a read-only admin user to our reference server deployment. This way, anyone can login and see the transactions being processed.

Or POST /webapp/submit_form. We should do this so that we can redirect to GET /webapp and not risk the form being resubmitted after a response from the POST endpoint.

stellar/stellar-protocol#489

We should create a mock interface for fake banking rails and have the reference server use it to provide an example for others.

In the SEP-10 spec, it mentions that there should be a SIGNING_KEY in the toml file for the client to verify in the challenge: https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0010.md#challenge

The client can also verify the server's signature to be sure the challenge is signed by the SIGNING_KEY from the server's stellar.toml.

We should add this key into our toml file

We need to create a KYC system that will allow anchors to customize the KYC pages with both their own branding and field definitions. We should ensure anchors can get any type of information they might need, including text, dates, photos (id), etc.

This task is to design what the API will look like for that and get feedback from SDF and anchors.

It's currently difficult to develop (outside of unit tests) and we should make it easier. The current solution isn't documented, but involves running a local PyPI server, and seems kind of complicated to do with docker.

We need to document how to get up and running and provide as smooth as possible of an experience to develop polaris features.

Looks like there was a Django vulnerability found and fixed in 2.2.8, we'll upgrade to this version.

We need a way to internationalize any human readable information coming from polaris. The most obvious is the Form UI in the interactive flow, but also includes things like error messages from api requests and asset information.

We should implement an internationalization solution, localize to one other language, and create documentation on how anchors should localize their own content.

As documented by #32

Form Integrations allows anchors to define what information needs to be collected from the user. But I've realized that the anchor may want to render non-form content to the user during the interactive flow.

Our particular use case is that when a user submits his/her KYC info (email), the anchor should confirm that the user actually owns that email. We'd do this by sending a confirmation email and rendering a "Please confirm your email before proceeding" page until they confirm. Once they confirm, we'd move on to filling out the rest of the forms.

We should rename form_for_transaction to content_for_transaction

When you submit the form from /interactive_deposit it succeeds and renders the more_info.html template, but the url is still /interactive_deposit. This makes it so you can't refresh the page without trying to re-submit the form and it errors out.

Instead, we should submit the form, then redirect to the more info url since we're done with interactive_deposit

We need to create an API that will work for a wide range of banking providers so that any anchor can plug their bank rails into polaris. This task is to create some documentation on an API and get buy-in from SDF and Anchor partners.

We should be monitoring our heroku deployment for stellar-anchor-server to ensure its has a good uptime. Runscope was suggested for this purpose, but we'll explore other options as well.

Confirge CircleCI to install the transfer server validator to test the reference server code about to be deployed.

We should add Google Analytics or an equivalent tool to our reference server.

One challenge I forsee for with this is that we cannot add the analytics script to our templates without affecting all Polaris deployments. This issue may have to wait until #32 is implemented.

We should add a KYC form to our reference server and start storing the user info in our DB. We want other anchors to do this so users do not have to repeatedly submit their KYC info for every transaction.

What problem does your feature solve?

Some users of Polaris want to be able to add additional fields to the forms we use during deposit and withdraw flows, but right now developers must fork the source code in order to extend the form.

What would you like to see?

A clear interface for extending or replacing the forms used in the deposit and withdraw flows.

We'd like to provide a page (not shown in the deposit/withdraw flow) in the reference server that has all possible form fields. This can be used as a style/content reference for other anchors.

Implementation ticket for #17
Design

Two reasons for doing this:

• Reloading a form that was returned directly from a POST request would re-submit the form. It would be better to redirect to the GET endpoint instead of responding directly.
• Authentication is much simpler for the POST requests and should be in a separate decorator.

What problem does your feature solve?

Polaris does not implement any banking rails, which is different for every anchor. Therefore we need to implement an interface for developers to use to integrate their banking rails in order for this to be used without forking the source code.

What would you like to see?

A clear set of classes/functions that provide developers the structure needed to integrate their banking rails with Polaris.

What problem does your feature solve?

Anchors need to be able to adjust the information collected for KYC, but currently have no way of doing that without forking the codebase.

What would you like to see?

A design for form integrations that allows for the anchor to define and validate forms registered with polaris. It should the same pattern as #10 for consistency.

What should this feature provide?

It should provide an API for defining forms.

• This includes the field list and associated validation functions. This can be done with Django Forms.
  It should provide a function for processing the information post-validation
• The anchors could use this to persist some of the information collected.

Once the form is validated and processed, the polaris endpoint using the custom form would resume control to continue the withdraw or deposit flow.