stellar-deprecated / bridge-server Goto Github PK
View Code? Open in Web Editor NEWDeprecated. Go to https://github.com/stellar/go/tree/master/services/bridge
License: Apache License 2.0
Deprecated. Go to https://github.com/stellar/go/tree/master/services/bridge
License: Apache License 2.0
Ex. does not return any relevant information when invalid JSON is passed in AuthRequest.Data.
in bridge server they are called "hooks" in compliance server they are called "callbacks" it doesnt matter which we use but they should be consistent between both.
This will possibly be moved to a different project later but in the meantime lets just have it here.
input:
handling the request:
return: horizon response or an error
needs triaging. see src/github.com/stellar/gateway/horizon/internal.go
for parseEvent
function that throws this error
config_bridge.toml
-> bridge.cfg
config_compliance.toml
-> compliance.cfg
I know this used to work, but I haven't tried earlier versions of bridge. I'm trying this on v0.0.18.
curl -X POST -d \
"source=SBT54H3GKVLDDT2WN4E5YWCWEULU2UICOJ6WEQV436UZMMPBTQTMLQG2&\
amount=1&\
destination=GDMDBRU7C3AESSHRN3W7CQL7QV6SAZKSEJU5W7O2BOVERQODKHW2RQFP&\
memo_type=id&\
memo=125" \
https://bridgeserver/payment
returns:
{
"code": "missing_parameter",
"message": "Required parameter is missing.",
"data": {
"name": "destination"
}
}
It’s possible I’m misunderstanding the flow here, but when posting to the compliance server’s internal /send
endpoint, it seems like the sanctions
callback should be called with the info obtained from the foreign compliance server before returning a 200 OK response. Step 6 in the compliance protocol doc would seem to indicate the same.
As it stands, setting needs_auth
merely tells the other compliance server to send back info on the receiver (which it does), but then does nothing with that info other than pass it back in the result to /send
. If the entity that called /send
was the bridge server, we also know the bridge server does nothing with this info.
If connected to a compliance server it should hit the /receive_payment endpoint and reject the payment if the compliance server hasn't approved.
It would be nice if bridge and compliance server printed their version if you run
./bridge -V
I'm looking to build an app that will watch multiple addresses, without knowing them ahead of time. It looks like my option today is to subscribe to the stream straight from my app. Since bridge already does this but for one address at a time, perhaps the addresses being watched can be database-driven so multiple ones can be created.
address
fieldDoes this sound like a feature that fits the scope of the bridge server?
The docs suggest that the base_seed
configuration parameter will be used to determine the transaction source for payments, but the source
param is still required anyway (https://github.com/stellar/bridge-server/blob/0.0.12/src/github.com/stellar/gateway/protocols/bridge/payment.go#L63) and there certainly doesn't appear to be any code for the fallback anyway (https://github.com/stellar/bridge-server/blob/0.0.12/src/github.com/stellar/gateway/protocols/bridge/payment.go#L128)
As a side note: what is the point of that config param if this doesn't work?
We should probably stuff it in the compliance config, and add it to to the Stellar.org/developers docs.
When a transaction has more than one payment operation, it only saves the first payment operation and then logs Payment already exists
. it does not save the other operations.
This will fix the case where they call /payment but never hear back. They don't know if they should re-post or if the tx was sent.
uniqueID should just be an opaque string.
The stellar.toml will tell you if it does.
The compliance readme currently lists the encryption_key
config property as “not working yet,” but it is still required in the configuration validation routine: https://github.com/stellar/bridge-server/blob/master/src/github.com/stellar/gateway/compliance/config/config.go#L59-L62
Should it be optional until support for it is implemented? If not, we should probably at least update the readme to clarify that you still have to specify it (and it has to be valid).
https://github.com/stellar/bridge-server/blob/master/readme_compliance.md#callbacks this section doesn't exist.
Seems like this should at least be called for payments received with assets you don't accept. Not sure what else should trigger it.
When there's a problem connecting to Horizon try to reconnect instead of exiting.
looks like it has the bridge server example config
Instead, show error if there was an error reconnecting.
This will involve changing the /send and /payment endpoints to accept a destination currency. If it is different than the sending currency then you must do the path find before you create the tx.
In writing the new anchor guide, I was at first a little confused to find that I had to specify extra_memo
in the payment parameters to the bridge server in order to trigger usage of the compliance server (in my first several attempts, I had left it empty and couldn’t figure out why I wasn’t seeing any compliance activity).
After looking through the source, I definitely understand that using extra_memo
as a shorthand prevents hitting the receiver’s stellar.toml
(especially since the compliance server will do it again), but from a user perspective, this still seems a little awkward. Maybe the compliance server could respond with a special status code to indicate that no compliance was necessary or maybe the bridge server could pass along the foreign stellar.toml
data?
In many cases the sender needs to get additional info from the receiver after the payment is sent. To either tell their customer or for their own records.
After a tx is approved by the compliance protocol and submitted to Stellar, the sender can call /tx_status
to learn what happened to the tx.
/tx_status?sender=bob*domain.com&id=tx_id&sig=<sig>
return
{
status: {unknown,pending,ok,failed,refunded},
recv_code: <arbitrary string>,
refund_tx: <tx_hash>,
msg: <arbitrary string>
}
sig
is the tx_id signed by the sending domain using the same signature mechanism used in the compliance protocol.
refund_tx
only appears if the status is "refunded". It will be the txID of the tx sending the money back. The address to send the refund to needs to be sent as part of the original payment attachment otherwise the receiver won't know how to refund.
right now code is duplicated between both
Right now it returns any error as 400 and its opaque to the caller what is going on. at least with /payment
Using the v0.0.17 Linux binary, I getting the error on shown in the title when I provide -c
or --config
.
Here's the full error:
INFO[0000] Applied migrations: 0
INFO[0000] Creating and initializing TransactionSubmitter
INFO[0000] Initializing Authorizing account
INFO[0000] Loading account accountID=GAT6VDPXX26XXFAKACUJTIZAL3GSFJ4NECG7B3C3P63IP4233XFP2PCS service=Horizon
INFO[0001] Account loaded accountID=GAT6VDPXX26XXFAKACUJTIZAL3GSFJ4NECG7B3C3P63IP4233XFP2PCS service=Horizon
INFO[0001] Initializing Base account
INFO[0001] TransactionSubmitter created
INFO[0001] Creating and starting PaymentListener
WARN[0001] No callbacks.receive param. Skipping...
flag provided but not defined: -c
Usage of bridge:
-bind string
Address to bind on. If this value has a colon, as in ":8000" or
"127.0.0.1:9001", it will be treated as a TCP address. If it
begins with a "/" or a ".", it will be treated as a path to a
UNIX socket. If it begins with the string "fd@", as in "fd@3",
it will be treated as a file descriptor (useful for use with
systemd, for instance). If it begins with the string "einhorn@",
as in "einhorn@0", the corresponding einhorn socket will be
used. If an option is not explicitly passed, the implementation
will automatically select among "einhorn@0" (Einhorn), "fd@3"
(systemd), and ":8000" (fallback) based on its environment. (default ":8001")
-httptest.serve string
if non-empty, httptest.NewServer serves on this address and blocks
This is the result of bridge --help
:
stellar bridge server
Usage:
bridge [flags]
Flags:
-c, --config string path to config file (default "bridge.cfg")
--migrate-db migrate DB to the newest schema version
time="2017-09-07T08:39:38Z" level=warning msg="Error persisting /allow entity" err="Error 1146: Table 'compliance.AllowedFi' doesn't exist"
Should we add an endpoint that builds txs for them maybe from some json object or something?
This would allow people to do arbitrary txs without having a lib to build the XDR.
Something like:
{
ops: [
{
type: allow_trust,
issuer: GBEZOC5U4TVH7ZY5N3FLYHTCZSI6VFGTULG7PBITLF5ZEBPJXFT46YZM,
asset_code: "BTC"
},
{
type: set_options,
inflation_dest: GBEZOC5U4TVH7ZY5N3FLYHTCZSI6VFGTULG7PBITLF5ZEBPJXFT46YZM
}
]
An alternative would be an endpoint that will do the change trust operation since other than payment this is probably the most common.
@nullstyle I bet you have thoughts here.
Having --conf
in both bridge
and compliance
for that would be great!
This is one of two issues that had me pretty much stumped for more than a day. In the 0.0.12 release of bridge server (haven't checked compliance server for this issue yet), the bindata.go
file that holds the migrations for mysql is not up-to-date with the actual migration .sql
files. So if you call:
./bridge --migrate-db
…as recommended in the readme, you get a DB that doesn't actually work. (Specifically, the SentTransaction
table is missing the transaction_id
column.)
It seems pretty obvious that this was a result of the .sql
getting updated, but someone forgetting to manually run go-bindata -o bindata.go migrations_*
from each db/drivers/*
directory. I imagine it would be a very good idea to simply script that as part of the build process somehow (I'm not familiar enough with gb
to know if there's a way to do that without wrapping it).
Further, maybe it would be a good idea to do a 0.0.13
hotfix-ish release that fixes the SentTransaction
table? And it should at least be done in whatever the next normal release is.
(It is worth mentioning: the bindata.go
for mysql appears to be up-to-date in master.)
Currently it appears that the compliance server can return several responses on the sanctions check.
We need the ability to pass back validation errors. For example if the country code is not iso2, or birthdate is not iso format. This could be 400 + text or maybe 422 as per this discussion. https://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate
It strikes me that the common case for bridge server is for the ReceivingAccountID
to be the account ID that corresponds to BaseSeed
(please correct me if this seems way off base). Would it be a useful convenience to generate it from BaseSeed
if none is provided?
The documentation for bridge server notes that if the server is configured with an api_key
option, a corresponding parameter named api_key
must be included with all requests (https://github.com/stellar/bridge-server/blob/master/readme_bridge.md#config).
However, the actual parameter in the request is apiKey
(https://github.com/stellar/bridge-server/blob/master/src/github.com/stellar/gateway/server/middlewares.go#L42).
Not sure whether the documentation just needs to change to reflect reality or the parameter name should change. In an ideal world, it seems like the latter would be better (so it is in keeping with the naming convention for all other params), but if anyone is using it, that could easily break them. Maybe accept both?
The readme for compliance currently states that if the ask_user
callback is not specified, “then the customer information won't be given to the other FI.” This isn’t actually true—it falls back to users and domains that have been whitelisted using the allow_access
endpoint.
Additionally, the description of the allow_access
endpoint and its effects is incredibly unclear. I definitely didn’t understand it until I spent some time browsing the source, which a user definitely should not need to do.
in the config docs
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.