From d4a03e322349da9ceeb4e26394f0903881f914cc Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 13:55:42 +0100 Subject: ingestion test API --- libeufin/api-nexus.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index 01e8e926..5470707d 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -103,6 +103,20 @@ User Management Return list of users. +Test API +-------- + +.. http:post:: {nexusBase}/bank-accounts/{acctid}/test-camt-ingestion/{type} + + This call allows tests to **directly** give Nexus a Camt document. After + the processing, all the payment(s) details should be ingested as if the + Camt came normally from a bank / the Sandbox. + + **Response** + + The successful case should respond with a ``200 OK`` and a empty JSON body. + + Bank Accounts ------------- -- cgit v1.2.3 From afec3965583eff04bffa62bd4b53dc9de682ff32 Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 14:05:09 +0100 Subject: fix API description --- libeufin/api-nexus.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index 5470707d..6cf52190 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -110,7 +110,9 @@ Test API This call allows tests to **directly** give Nexus a Camt document. After the processing, all the payment(s) details should be ingested as if the - Camt came normally from a bank / the Sandbox. + Camt came normally from a bank / the Sandbox. ``acctid`` must match the + label of a locally imported bank account, and ``type`` for now can only be + ``C53``. **Response** -- cgit v1.2.3 From e4d9639bcb53cdf7968bd5eb87bd94f33bb73ccd Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 14:56:21 +0100 Subject: match implementation --- libeufin/api-nexus.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index 6cf52190..b7186f16 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -297,7 +297,8 @@ manages payment initiations of the account and tracks the initiations of payment Optional, defaults to "earliest possible" date. - **Response:** A list of `Transaction` objects. + **Response:** A object with a unique field named ``transactions`` + that contains a list of `Transaction` objects. .. ts:def:: Transaction -- cgit v1.2.3 From f1d0199a830e6b354c5d49b4dd8b0e1bea0c828e Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 15:47:54 +0100 Subject: Align specs to code. --- libeufin/api-nexus.rst | 72 +++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 56 insertions(+), 16 deletions(-) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index b7186f16..67ac3c3e 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -303,28 +303,68 @@ manages payment initiations of the account and tracks the initiations of payment .. ts:def:: Transaction interface Transaction { - // local bank account involved in the transaction. - account: string; - // counterpart IBAN - counterpartIban: string; + // money moved by the transaction + amount: string; - // counterpart BIC - counterpartBic: string; + // CRDT or DBIT + creditDebitIndicator: string - // counterpart holder name - counterpartName: string; + // Two of the most used values are BOOK, or PENDING + status: string; - // amount, in the format [-]CURRENCY:XX.YY, - // where the minus sign as prefix indicates - // a debit for the user's bank account. - amount: string; + // FIXME + bankTransactionCode: string; - // Dashed date YYYY-MM(01-12)-DD(01-31) of the transaction. - date: string; + // FIXME + valueDate: string; + + // When this payment got booked. In the form YYYY-MM-DD + bookingDate: string; - // Payment subject. - subject: string; + // FIXME + accountServicerRef: string; + + // FIXME + batches: { + // list of batched transactions + batchTransactions: [BatchedTransaction] + }; + } + + .. ts:def:: BatchedTransaction + interface BatchedTransaction { + // FIXME + amount: string; + // FIXME + creditDebitIndicator: string; + // FIXME + details { + debtor: { + name: string; + }; + debtorAccount: { + iban: string; + }; + // Missing, when the payment is DBIT. + debtorAgent: { + bic: string; + }; + creditor: { + name: string; + }; + creditorAccount: { + iban: string; + }; + // Missing, when the payment is CRDT. + creditorAgent: { + iban: string; + }; + // FIXME + endToEndId: string; + // FIXME + unstructuredRemittanceInformation: string; + } } -- cgit v1.2.3 From 48611f18bd748d4fce4ac04b99413d6b25020e98 Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 16:00:00 +0100 Subject: fix rendering --- libeufin/api-nexus.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index 67ac3c3e..33e88b21 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -333,6 +333,7 @@ manages payment initiations of the account and tracks the initiations of payment } .. ts:def:: BatchedTransaction + interface BatchedTransaction { // FIXME amount: string; -- cgit v1.2.3 From 85bf438809488f552d639fd04e13989a74a6cb95 Mon Sep 17 00:00:00 2001 From: MS Date: Thu, 3 Dec 2020 16:01:39 +0100 Subject: fix rendering --- libeufin/api-nexus.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'libeufin') diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst index 33e88b21..f47101fd 100644 --- a/libeufin/api-nexus.rst +++ b/libeufin/api-nexus.rst @@ -328,7 +328,7 @@ manages payment initiations of the account and tracks the initiations of payment // FIXME batches: { // list of batched transactions - batchTransactions: [BatchedTransaction] + batchTransactions: BatchedTransaction[]; }; } -- cgit v1.2.3 From ea4bfb4f8903c2cb73f82b4f940323af745bf2b9 Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Fri, 4 Dec 2020 04:06:16 -0500 Subject: use ‘.. code-block:: console’ (88 instances) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- libeufin/nexus-tutorial.rst | 166 ++++++++++++++++++++-------------------- taler-auditor-manual.rst | 30 ++++---- taler-backoffice-manual.rst | 6 +- taler-exchange-manual.rst | 32 ++++---- taler-merchant-manual.rst | 132 ++++++++++++++++---------------- taler-merchant-pos-terminal.rst | 2 +- taler-nfc-guide.rst | 8 +- taler-wallet.rst | 18 ++--- 8 files changed, 197 insertions(+), 197 deletions(-) (limited to 'libeufin') diff --git a/libeufin/nexus-tutorial.rst b/libeufin/nexus-tutorial.rst index 82f1ba43..e919ed8c 100644 --- a/libeufin/nexus-tutorial.rst +++ b/libeufin/nexus-tutorial.rst @@ -16,7 +16,7 @@ Obtain Nexus ============ Nexus belongs to the LibEuFin project, and can be downloaded via Git: -.. code-block:: shell +.. code-block:: console $ git clone git://git.taler.net/libeufin @@ -26,14 +26,14 @@ Install Nexus ============= Navigate into the `libeufin` local repository, and from top-level run: -.. code-block:: shell +.. code-block:: console $ ./gradlew -Pprefix=$PREFIX nexus:installToPrefix $ ./gradlew -Pprefix=$PREFIX cli:installToPrefix In case of success, the two following commands should be found: -.. code-block:: shell +.. code-block:: console $ which libeufin-nexus $ which libeufin-cli @@ -43,7 +43,7 @@ Connect Nexus with a EBICS account Use the following command to *(1) run the nexus service*: -.. code-block:: shell +.. code-block:: console $ libeufin-nexus @@ -55,7 +55,7 @@ for PostgreSQL will be provided. At this point a *(2) superuser account needs to be activated into the system*: -.. code-block:: shell +.. code-block:: console $ libeufin-nexus superuser foo # Will interactively ask for password @@ -75,74 +75,74 @@ creating a EBICS connection*. set to ``foo``, and ``NEXUS_PASSWORD`` to the value given for its password in step (2). -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connections \ - new-ebics-connection \ - --ebics-url $EBICS_BASE_URL \ - --host-id $EBICS_HOST_ID \ - --partner-id $EBICS_PARTNER_ID \ - --ebics-user-id $EBICS_USER_ID \ - $CONNECTION_NAME + $ libeufin-cli \ + connections \ + new-ebics-connection \ + --ebics-url $EBICS_BASE_URL \ + --host-id $EBICS_HOST_ID \ + --partner-id $EBICS_PARTNER_ID \ + --ebics-user-id $EBICS_USER_ID \ + $CONNECTION_NAME If the step above executed correctly, Nexus created all the cryptographic material that is needed on the client side; in this EBICS example, it created the signature and identification keys. It is therefore advisable to *(4) make a backup copy* of such keys. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connections \ - export-backup \ - --passphrase $SECRET \ - --outputfile $BACKUP_FILE \ - $CONNECTION_NAME + $ libeufin-cli \ + connections \ + export-backup \ + --passphrase $SECRET \ + --outputfile $BACKUP_FILE \ + $CONNECTION_NAME At this point, Nexus must communicate all the details to the bank. Therefore, it will *(5) synchronize the connection*. In this EBICS example, Nexus will send the *INI* and *HIA* messages to the bank. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connections \ - sync \ - $CONNECTION_NAME + $ libeufin-cli \ + connections \ + sync \ + $CONNECTION_NAME Once the connection is synchronized, Nexus needs to import locally the data corresponding to the bank accounts offered by the bank connection just made. The command below *(6) downloads the list of the bank accounts offered by the* ``$CONNECTION_NAME``. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connections \ - download-bank-accounts \ - $CONNECTION_NAME + $ libeufin-cli \ + connections \ + download-bank-accounts \ + $CONNECTION_NAME It is now possible to *(7) list the accounts offered by the connection*. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connections \ - list-offered-bank-accounts \ - $CONNECTION_NAME + $ libeufin-cli \ + connections \ + list-offered-bank-accounts \ + $CONNECTION_NAME Nexus now needs an explicit *(8) import of the accounts it needs to manage*. This step is needed to let the user pick a custom name for such accounts. -.. code-block:: shell +.. code-block:: console - libeufin-cli - connections \ - import-bank-account \ - --offered-account-id $ACCOUNT_NATIVE_NAME \ - --nexus-bank-account-id $CUSTOM_RENAMING_FOR_ACCOUNT \ - $CONNECTION_NAME + $ libeufin-cli + connections \ + import-bank-account \ + --offered-account-id $ACCOUNT_NATIVE_NAME \ + --nexus-bank-account-id $CUSTOM_RENAMING_FOR_ACCOUNT \ + $CONNECTION_NAME Once a Nexus user imported a bank account (``$CUSTOM_RENAMING_FOR_ACCOUNT``) under a certain connection (``$CONNECTION_NAME``), it is possible @@ -161,22 +161,22 @@ from the bank, and then ask it again to return the results. This command asks Nexus to *download the latest bank statements*: -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - accounts \ - fetch-transactions \ - $CUSTOM_RENAMING_FOR_ACCOUNT + $ libeufin-cli \ + accounts \ + fetch-transactions \ + $CUSTOM_RENAMING_FOR_ACCOUNT Once Nexus stored all the information in the database, the client can ask to actually **see** the transactions: -.. code-block:: shell +.. code-block:: console - libeufin-cli - accounts \ - transactions \ - $CUSTOM_RENAMING_FOR_ACCOUNT + $ libeufin-cli + accounts \ + transactions \ + $CUSTOM_RENAMING_FOR_ACCOUNT Make a payment ============== @@ -188,17 +188,17 @@ Payments pass through two phases: preparation and submission. The following command prepares a payment: -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - accounts \ - prepare-payment \ - --credit-iban $IBAN_TO_SEND_MONEY_TO \ - --credit-bic $BIC_TO_SEND_MONEY_TO \ - --credit-name $LEGAL_ENTITY_RECEIVING_THE_PAYMENT \ - --payment-amount $AMOUNT \ - --payment-subject $SUBJECT \ - $CUSTOM_RENAMING_FOR_ACCOUNT + $ libeufin-cli \ + accounts \ + prepare-payment \ + --credit-iban $IBAN_TO_SEND_MONEY_TO \ + --credit-bic $BIC_TO_SEND_MONEY_TO \ + --credit-name $LEGAL_ENTITY_RECEIVING_THE_PAYMENT \ + --payment-amount $AMOUNT \ + --payment-subject $SUBJECT \ + $CUSTOM_RENAMING_FOR_ACCOUNT Note: the ``$AMOUNT`` value needs the format ``X.Y:CURRENCY``; for example ``10:EUR``, or ``1.01:EUR``. @@ -207,13 +207,13 @@ The previous command should return a value (``$UUID``) that uniquely identifies the prepared payment in the Nexus system. It'll be needed in the next step, to **send the payment instructions to the bank**: -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - accounts \ - submit-payment \ - --payment-uuid $UUID \ - $CUSTOM_RENAMING_FOR_ACCOUNT + $ libeufin-cli \ + accounts \ + submit-payment \ + --payment-uuid $UUID \ + $CUSTOM_RENAMING_FOR_ACCOUNT Restore the backup @@ -224,14 +224,14 @@ associated with one bank connection subscription. For EBICS, this means that the INI and HIA secret keys will be restored for the requesting user. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - connection \ - restore-backup \ - --passphrase $SECRET \ - --outputfile $BACKUP_FILE \ - $CONNECTION_NAME + $ libeufin-cli \ + connection \ + restore-backup \ + --passphrase $SECRET \ + --outputfile $BACKUP_FILE \ + $CONNECTION_NAME Creating a Taler facade ======================= @@ -245,14 +245,14 @@ At this moment, only the *Taler facade type* is implemented in the Nexus, and the command below will show how to instantiate one under an existing bank account. -.. code-block:: shell +.. code-block:: console - libeufin-cli \ - taler-facade \ - new-facade \ - --facade-name $FACADE_NAME \ - $CONNECTION_NAME \ - $CUSTOM_RENAMING_FOR_ACCOUNT + $ libeufin-cli \ + taler-facade \ + new-facade \ + --facade-name $FACADE_NAME \ + $CONNECTION_NAME \ + $CUSTOM_RENAMING_FOR_ACCOUNT At this point, the additional *taler-wire-gateway* (link here) API becomes offered by the Nexus. The purpose is to let a Taler exchange diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index 35f5a799..8faadb6a 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -221,7 +221,7 @@ to export some of the tooling required by Taler. To download and install libgnunetutil, proceed as follows: -:: +.. code-block:: console $ git clone https://git.gnunet.org/gnunet/ $ cd gnunet/ @@ -237,7 +237,7 @@ which requires you to run the last step as ``root``. To download and install the GNU Taler exchange, proceeds as follows: -:: +.. code-block:: console $ git clone git://git.taler.net/exchange $ cd exchange @@ -370,9 +370,9 @@ If this step is skipped, the auditor will malfunction at all future stages with a foreign key violation, as it doesn't know the exchange's master public key. -:: +.. code-block:: console - taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL + $ taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL .. _AuditorDenominations: @@ -392,9 +392,9 @@ receive the blob to sign (Website, manual delivery, ...). Note that the blob does not contain confidential data, but signing the wrong keys would be fatal. Given the blob, the auditor would sign it using: -:: +.. code-block:: console - taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE + $ taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE Those arguments are all mandatory. @@ -467,7 +467,7 @@ Performing an audit is done by invoking the ``taler-auditor`` and files, which can then be combined using the ``contrib/render.py`` script into the TeX report. -:: +.. code-block:: console $ taler-audit @@ -510,7 +510,7 @@ several categories of failures of different severity: the correct amount to a merchant). - Configuration issues (such was wire fees unavailable) - + .. _AuditorDatabaseUpgrades: @@ -520,9 +520,9 @@ Database upgrades To upgrade the database between Taler versions can be done by running: -:: +.. code-block:: console - $ taler-auditor-dbinit + $ taler-auditor-dbinit However, the above is the general rule. Please review the specific release notes to ensure this is correct for the @@ -531,7 +531,7 @@ specific upgrade. The auditor database can be re-initialized using: -:: +.. code-block:: console $ taler-auditor-dbinit -r @@ -654,7 +654,7 @@ CodeBlau reports the following checks: coin value without fee, total deposit without refunds - wire out fee is negative - + - coin arithmetic inconsistencies - refund (merchant) is negative @@ -672,13 +672,13 @@ CodeBlau reports the following checks: - wire out inconsistencies in amount - row inconsistencies - + - wire account given is malformed - h(wire) does not match wire - failed to compute hash of given wire data - + - database contains wrong hash code for wire details - no transaction history for coin claimed in aggregation @@ -715,7 +715,7 @@ CodeBlau reports the following checks: - arithmetic inconsistencies - melt contribution vs. fee - + - melt (cost) - refund fee diff --git a/taler-backoffice-manual.rst b/taler-backoffice-manual.rst index d87f100e..d9c57f2c 100644 --- a/taler-backoffice-manual.rst +++ b/taler-backoffice-manual.rst @@ -26,7 +26,7 @@ The back-office Web service code is available at ``git://taler.net/backoffice``. The application can be installed in a GNU-ish fashion. -:: +.. code-block:: console # Get the code: $ git clone git://taler.net/backoffice @@ -120,9 +120,9 @@ Launching the backoffice The following example shows how to run the Web service. -:: +.. code-block:: console - # such invocation will work only if the configuration contains + # Such invocation will work only if the configuration contains # a section called "[backoffice-myshop]" which looks like the # example above. diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst index 0b038216..7e132d79 100644 --- a/taler-exchange-manual.rst +++ b/taler-exchange-manual.rst @@ -257,7 +257,7 @@ to export some of the tooling required by Taler. To download and install libgnunetutil, proceed as follows: -:: +.. code-block:: console $ git clone git://git.gnunet.org/gnunet $ cd gnunet/ @@ -273,7 +273,7 @@ which requires you to run the last step as ``root``. To download and install the GNU Taler exchange, proceeds as follows: -:: +.. code-block:: console $ git clone git://git.taler.net/exchange $ cd exchange @@ -340,7 +340,7 @@ by defining them under a ``[paths]`` section, see example below, or by setting them in the environment: -:: +.. code-block:: console $ export VAR=/x @@ -378,7 +378,7 @@ file format and can also be edited by hand. Run -:: +.. code-block:: console $ taler-config -s $SECTION @@ -386,7 +386,7 @@ to list all of the configuration values in section ``$SECTION``. Run -:: +.. code-block:: console $ taler-config -s $section -o $option @@ -395,7 +395,7 @@ section ``$section``. Finally, to change a setting, run -:: +.. code-block:: console $ taler-config -s $section -o $option -V $value @@ -408,7 +408,7 @@ their value. To expand the ``$DATADIR`` or other $-variables in the configuration, pass the ``-f`` option to ``taler-config``. For example, compare: -:: +.. code-block:: console $ taler-config -s ACCOUNT-bank \ -o WIRE_RESPONSE @@ -530,7 +530,7 @@ The command line tool taler-exchange-wire is used to create the follows to create all of the WIRE_RESPONSE files (in the locations specified by the configuration): -:: +.. code-block:: console $ taler-exchange-wire @@ -741,9 +741,9 @@ by the tool ``taler-exchange-keyup``. The following command generates denomkeys and signkeys, plus the "blob" that is to be signed by the auditor. -:: +.. code-block:: console - taler-exchange-keyup -o blob + $ taler-exchange-keyup -o blob *blob* contains data about denomkeys that the exchange operator needs to get signed by every auditor he wishes (or is forced to) work with. @@ -753,9 +753,9 @@ blob to sign (Website, manual delivery, ..). Nonetheless, the exchange admin can fake an auditor signature — for testing purposes — by running the following command -:: +.. code-block:: console - taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE + $ taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o OUTPUT_FILE Those arguments are all mandatory. @@ -775,9 +775,9 @@ option ``AUDITOR_BASE_DIR`` under the section ``[exchangedb]``. Assuming following command will "add" the auditor identified by ``AUDITOR_URL`` to the exchange. -:: +.. code-block:: console - cp OUTPUT_FILE ${HOME}/.local/share/taler/auditors + $ cp OUTPUT_FILE ${HOME}/.local/share/taler/auditors If the auditor has been correctly added, the exchange’s ``/keys`` response must contain an entry in the ``auditors`` array mentioning the @@ -793,7 +793,7 @@ versions. The exchange database can be re-initialized using: -:: +.. code-block:: console $ taler-exchange-dbinit -r @@ -1008,7 +1008,7 @@ initialized using ``taler-exchange-keyup``. You can run a first simple benchmark using: -:: +.. code-block:: console $ createdb talercheck # if it does not yet exist $ taler-exchange-keyup -c benchmark.conf diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst index 617cc773..bf69c499 100644 --- a/taler-merchant-manual.rst +++ b/taler-merchant-manual.rst @@ -396,7 +396,7 @@ First, unpack the GNU Taler merchant tarball and change into the resulting directory. Then, use the following commands to build and install the merchant backend: - :: +.. code-block:: console $ ./configure [--prefix=PFX] \ [--with-gnunet=GNUNETPFX] \ @@ -439,7 +439,7 @@ On Debian stretch, only GNU libmicrohttpd needs to be compiled from source. To install dependencies on Debian stretch, run the following commands: - :: +.. code-block:: console # apt-get install \ libltdl-dev \ @@ -461,7 +461,7 @@ commands: For more recent versions of Debian, you should instead run: - :: +.. code-block:: console # apt-get install \ libltdl-dev \ @@ -547,10 +547,10 @@ the backend to the network. To run the Taler backend on TCP port 8888, use: - :: +.. code-block:: console - $ taler-config -s MERCHANT -o SERVE -V TCP - $ taler-config -s MERCHANT -o PORT -V 8888 + $ taler-config -s MERCHANT -o SERVE -V TCP + $ taler-config -s MERCHANT -o PORT -V 8888 @@ -568,9 +568,9 @@ For testing purposes, the currency MUST match “KUDOS” so that tests will work with the Taler demonstration exchange at https://exchange.demo.taler.net/: - :: +.. code-block:: console - $ taler-config -s TALER -o CURRENCY -V KUDOS + $ taler-config -s TALER -o CURRENCY -V KUDOS Database @@ -601,33 +601,33 @@ Postgres database you want to use. Suppose ``$USER`` is the name of the user who will run the backend process. Then, you need to first run - :: +.. code-block:: console - $ sudo -u postgres createuser -d $USER + $ sudo -u postgres createuser -d $USER as the Postgres database administrator (usually ``postgres``) to grant ``$USER`` the ability to create new databases. Next, you should as ``$USER`` run: - :: +.. code-block:: console - $ createdb $DBNAME + $ createdb $DBNAME to create the backend’s database. Here, ``$DBNAME`` must match the database name given in the configuration file. To configure the Taler backend to use this database, run: - :: +.. code-block:: console - $ taler-config -s MERCHANTDB-postgres -o CONFIG \ - -V postgres:///$DBNAME + $ taler-config -s MERCHANTDB-postgres -o CONFIG \ + -V postgres:///$DBNAME Now you should create the tables and indices. To do this, run as ``$USER``: - :: +.. code-block:: console - $ taler-merchant-dbinit + $ taler-merchant-dbinit You can improve your security posture if you now REVOKE the rights to CREATE, @@ -650,29 +650,29 @@ section, the following options need to be configured: - The “EXCHANGE_BASE_URL” option specifies the exchange’s base URL. For example, to use the Taler demonstrator, specify: - :: + .. code-block:: console $ taler-config -s MERCHANT-EXCHANGE-demo \ - -o EXCHANGE_BASE_URL \ - -V https://exchange.demo.taler.net/ + -o EXCHANGE_BASE_URL \ + -V https://exchange.demo.taler.net/ - The “MASTER_KEY” option specifies the exchange’s master public key in base32 encoding. For the Taler demonstrator, use: - :: + .. code-block:: console $ taler-config -s MERCHANT-EXCHANGE-demo \ - -o MASTER_KEY \ - -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00 + -o MASTER_KEY \ + -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00 - The “CURRENCY” option specifies the exchange’s currency. For the Taler demonstrator, use: - :: + .. code-block:: console $ taler-config -s MERCHANT-EXCHANGE-demo \ - -o CURRENCY \ - -V KUDOS + -o CURRENCY \ + -V KUDOS Note that multiple exchanges can be added to the system by using different tokens in place of ``demo`` in the example above. Note that all of the @@ -693,29 +693,29 @@ that section, the following options need to be configured: - The “AUDITOR_BASE_URL” option specifies the auditor’s base URL. For example, to use the Taler demonstrator's auditor, specify: - :: + .. code-block:: console $ taler-config -s MERCHANT-AUDITOR-demo \ - -o AUDITOR_BASE_URL \ - -V https://exchange.demo.taler.net/ + -o AUDITOR_BASE_URL \ + -V https://exchange.demo.taler.net/ - The “AUDITOR_KEY” option specifies the auditor's public key in base32 encoding. For the Taler demonstrator, use: - :: + .. code-block:: console $ taler-config -s MERCHANT-AUDITOR-demo \ - -o AUDITOR_KEY \ - -V FIXMEBADVALUENEEDTOGETTHERIGHTVALUEHEREEVENTUALLY000 + -o AUDITOR_KEY \ + -V FIXMEBADVALUENEEDTOGETTHERIGHTVALUEHEREEVENTUALLY000 - The “CURRENCY” option specifies the auditor’s currency. For the Taler demonstrator, use: - :: + .. code-block:: console $ taler-config -s MERCHANT-AUDITOR-demo \ - -o CURRENCY \ - -V KUDOS + -o CURRENCY \ + -V KUDOS Note that multiple auditors can be added to the system by using different @@ -783,7 +783,7 @@ Launching the backend Assuming you have configured everything correctly, you can launch the merchant backend as ``$USER`` using - :: +.. code-block:: console $ taler-merchant-httpd @@ -794,7 +794,7 @@ system for how to start and stop daemons. If everything worked as expected, the command - :: +.. code-block:: console $ curl http://localhost:8888/ @@ -883,7 +883,7 @@ For details, see the :ref:`contract terms ` specification. You can then create the instance using: - :: +.. code-block:: console $ wget --post-file=instance.json http://localhost:8888/private/instances @@ -916,10 +916,10 @@ Using UNIX domain sockets To ensure that the merchant backend is not exposed directly to the network, you *should* bind the backend to a UNIX domain socket: - :: +.. code-block:: console - $ taler-config -s MERCHANT -o SERVE -V UNIX - $ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock + $ taler-config -s MERCHANT -o SERVE -V UNIX + $ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock Do not use a UNIX domain socket path in "/tmp": systemd (or other init systems) may give Web servers a private "/tmp" thereby hiding UNIX domain @@ -958,11 +958,11 @@ Apache In Apache, make sure you have "mod_proxy", "mod_proxy_http" and "mod_headers" enabled: - :: +.. code-block:: console - a2enmod proxy - a2enmod proxy_http - a2enmod headers + $ a2enmod proxy + $ a2enmod proxy_http + $ a2enmod headers Then configure your Apache reverse proxy like this (you may change the endpoint): @@ -1053,9 +1053,9 @@ Apache For Apache, you should first enable "mod_rewrite": - :: +.. code-block:: console - a2enmod rewrite + $ a2enmod rewrite Then, you can restrict to an access control token using: @@ -1187,17 +1187,17 @@ manual), and then install the latest version of the code. If you REVOKED database permissions, ensure that the rights to CREATE, DROP, and ALTER tables are GRANTed to ``$USER`` again. Then, run: - :: +.. code-block:: console - $ taler-merchant-dbinit + $ taler-merchant-dbinit to upgrade the database to the latest schema. After that, you may again REVOKE the database permissions. Finally, restart the HTTP service, either via your systemd or init system, or directly using: - :: +.. code-block:: console - $ taler-merchant-httpd + $ taler-merchant-httpd .. _Tipping-visitors: @@ -1226,9 +1226,9 @@ First, the reserve must be setup in the merchant backend. A reserve is always tied to a particular instance. To create a reserve with 10 KUDOS at instance "default" using the demo exchange, use: - :: +.. code-block:: console - $ taler-merchant-setup-reserve \ + $ taler-merchant-setup-reserve \ -a KUDOS:10 \ -e https://exchange.demo.taler.net/ \ -m http://localhost:8888/instances/default @@ -1376,7 +1376,7 @@ by defining them under a ``[paths]`` section, see example below, or by setting them in the environment: -:: +.. code-block:: console $ export VAR=/x @@ -1416,7 +1416,7 @@ file format and can also be edited by hand. Run -:: +.. code-block:: console $ taler-config -s $SECTION @@ -1424,7 +1424,7 @@ to list all of the configuration values in section ``$SECTION``. Run -:: +.. code-block:: console $ taler-config -s $section -o $option @@ -1433,7 +1433,7 @@ section ``$section``. Finally, to change a setting, run -:: +.. code-block:: console $ taler-config -s $section -o $option -V $value @@ -1446,7 +1446,7 @@ their value. To expand the ``$DATADIR`` or other ``$``-variables in the configuration, pass the ``-f`` option to ``taler-config``. For example, compare: -:: +.. code-block:: console $ taler-config -s PATHS \ -o TALER_DATA_HOME @@ -1516,10 +1516,10 @@ exist before launching the benchmark. You also will need to ensure that the Exchange's details are setup, usually by running - :: +.. code-block:: console - taler-exchange-wire -c $CONFIG_FILE - taler-exchange-keyup -c $CONFIG_FILE + $ taler-exchange-wire -c $CONFIG_FILE + $ taler-exchange-keyup -c $CONFIG_FILE where "$CONFIG_FILE" should be replaced by the configuration file that is to be used. @@ -1551,7 +1551,7 @@ Any subcommand is also equipped with the canonical ``--help`` option, so feel free to issue the following command in order to explore all the possibilities. For example: -:: +.. code-block:: console $ taler-merchant-benchmark corner --help @@ -1610,14 +1610,14 @@ Because all of the Docker source file are kept in our “deployment“ repository, we start by checking out the ``git://git.taler.net/deployment`` codebase: -:: +.. code-block:: console $ git clone git://git.taler.net/deployment Now we actually build the merchant’s image. From the same directory as above: -:: +.. code-block:: console $ cd deployment/docker/merchant/ $ docker-compose build @@ -1625,7 +1625,7 @@ above: If everything worked as expected, the merchant is ready to be launched. From the same directory as the previous step: -:: +.. code-block:: console # Recall: the docker-machine should be up and running. $ docker-compose up @@ -1637,7 +1637,7 @@ message from postresql about already existing roles and databases. To test if everything worked as expected, it suffices to issue a simple request to the merchant, as: -:: +.. code-block:: console $ curl http://$(docker-machine ip)/ # A greeting message should be returned by the merchant. diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst index 8bf50315..b81eb33d 100644 --- a/taler-merchant-pos-terminal.rst +++ b/taler-merchant-pos-terminal.rst @@ -86,7 +86,7 @@ Building from source Import in and build with Android Studio or run on the command line: -.. code-block:: sh +.. code-block:: console $ git clone https://git.taler.net/merchant-terminal-android.git $ cd merchant-terminal-android diff --git a/taler-nfc-guide.rst b/taler-nfc-guide.rst index 81433878..1b3cfb18 100644 --- a/taler-nfc-guide.rst +++ b/taler-nfc-guide.rst @@ -48,7 +48,7 @@ using `curl `_ to make HTTP(S) requests. The following :http:post:`/private/orders` request to the merchant backend creates a simple order: - .. code-block:: sh + .. code-block:: console $ backend_base_url=https://backend.demo.taler.net/ $ auth_header='Authorization: ApiKey sandbox' @@ -71,7 +71,7 @@ using `curl `_ to make HTTP(S) requests. 2. The merchant checks the payment status of the order using :http:get:`/private/orders/$ORDER_ID`: - .. code-block:: sh + .. code-block:: console $ backend_base_url=https://backend.demo.taler.net/ $ auth_header='Authorization: ApiKey sandbox' @@ -97,7 +97,7 @@ using `curl `_ to make HTTP(S) requests. 3. The wallet processes the ``taler://pay/`` URI. In this example, we use the command-line wallet: - .. code-block:: sh + .. code-block:: console # Withdraw some toy money (KUDOS) from the demo bank $ taler-wallet-cli test-withdraw \ @@ -116,7 +116,7 @@ using `curl `_ to make HTTP(S) requests. 4. The merchant checks the payment status again: - .. code-block:: sh + .. code-block:: console $ backend_base_url=https://backend.demo.taler.net/ $ auth_header='Authorization: ApiKey sandbox' diff --git a/taler-wallet.rst b/taler-wallet.rst index d9f9d7fb..18ae0496 100644 --- a/taler-wallet.rst +++ b/taler-wallet.rst @@ -13,7 +13,7 @@ The command-line wallet is used primarily for testing by developers. Building from source -------------------- -.. code-block:: sh +.. code-block:: console $ git clone https://git.taler.net/wallet-core.git $ cd wallet-core @@ -30,7 +30,7 @@ The wallet can also obtained via NPM, the Node Package Manager. To install the wallet as a global package, run: -.. code-block:: sh +.. code-block:: console $ npm install -g taler-wallet # check if installation was successful @@ -38,7 +38,7 @@ To install the wallet as a global package, run: To install the wallet only for your user, run: -.. code-block:: sh +.. code-block:: console $ npm install -g --prefix=$HOME/local taler-wallet # check if installation was successful @@ -47,7 +47,7 @@ To install the wallet only for your user, run: To use the wallet as a library in your own project, run: -.. code-block:: sh +.. code-block:: console $ npm install taler-wallet @@ -55,7 +55,7 @@ To use the wallet as a library in your own project, run: Manual withdrawing ================== -.. code-block:: sh +.. code-block:: console $ taler-wallet-cli advanced withdraw-manually \ --exchange https://exchange.eurint.taler.net/ \ @@ -67,7 +67,7 @@ WebExtension Wallet Building from source -------------------- -.. code-block:: sh +.. code-block:: console $ git clone https://git.taler.net/wallet-core.git $ cd wallet-core @@ -1093,7 +1093,7 @@ the subcommands. If the database file doesn't exist, it will be created. The following example does a simple withdrawal recoup: -.. code-block:: sh +.. code-block:: console # Withdraw digital cash $ taler-wallet-cli --wallet-db=mydb.json testing withdraw \ @@ -1140,7 +1140,7 @@ The following example does a simple withdrawal recoup: To test refreshing, force a refresh: -.. code-block:: sh +.. code-block:: console $ taler-wallet-cli --wallet-db=mydb.json advanced force-refresh "$coin_pub" @@ -1148,7 +1148,7 @@ To test refreshing, force a refresh: To test zombie coins, use the timetravel option. It **must** be passed to the top-level command and not the subcommand: -.. code-block:: sh +.. code-block:: console # Update exchange /keys with time travel, value in microseconds $ taler-wallet-cli --timetravel=1000000 --wallet-db=mydb.json \ -- cgit v1.2.3 From e41cdf846de639bbb49ffc01ea830689605bccb2 Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 4 Dec 2020 12:52:03 +0100 Subject: Align specs to code. --- libeufin/api-sandbox.rst | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'libeufin') diff --git a/libeufin/api-sandbox.rst b/libeufin/api-sandbox.rst index d848ba40..a410b9ee 100644 --- a/libeufin/api-sandbox.rst +++ b/libeufin/api-sandbox.rst @@ -22,15 +22,28 @@ HTTP API // IBAN that will receive the payment. creditorIban: string; + // FIXME + creditorBic: string; + // FIXME + creditorName: string; // IBAN that will send the payment. debitorIban: string; + // FIXME + debitorBic: string; + // FIXME + debitorName: string; amount: string; currency: string; // subject of the payment. subject: string; + + // Whether the payment is credit or debit *for* the + // account being managed *by* the running sandbox. + // Can take the values: "CRDT" or "DBIT". + direction: string; } .. -- cgit v1.2.3 From 3b86fb44cf603b63bfb5f132def4f963b83ab17b Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 4 Dec 2020 13:07:12 +0100 Subject: more on Sandbox payments API --- libeufin/api-sandbox.rst | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) (limited to 'libeufin') diff --git a/libeufin/api-sandbox.rst b/libeufin/api-sandbox.rst index a410b9ee..6f1d152f 100644 --- a/libeufin/api-sandbox.rst +++ b/libeufin/api-sandbox.rst @@ -9,16 +9,33 @@ HTTP API .. Payments. +.. http:get:: /admin/payments + + Return the list of *all* the payments known by the sandbox. + + **Response** + + .. code-block:: tsref + + interface SandboxPayments { + + // The list of all known payments, regardless + // of any IBAN involved in them. + payments: SandboxPayment[]; + } + .. http:post:: /admin/payments Adds a new payment to the book. Mainly used for testing purposes. **Request:** + + One object of type `SandboxPayment` - .. ts:def:: PaymentRequest + .. ts:def:: SandboxPayment - interface PaymentRequest { + interface SandboxPayment { // IBAN that will receive the payment. creditorIban: string; -- cgit v1.2.3 From 085d99420a7aa23b04bd4ce1e256eec9e182c166 Mon Sep 17 00:00:00 2001 From: MS Date: Fri, 4 Dec 2020 13:22:49 +0100 Subject: Sandbox API. Endpoint to request a Camt document. --- libeufin/api-sandbox.rst | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'libeufin') diff --git a/libeufin/api-sandbox.rst b/libeufin/api-sandbox.rst index 6f1d152f..d1214d52 100644 --- a/libeufin/api-sandbox.rst +++ b/libeufin/api-sandbox.rst @@ -9,6 +9,31 @@ HTTP API .. Payments. + +.. http:post:: /admin/payments/camt + + Return the history of one IBAN in Camt.053 format. + + **Request** + + .. code-block:: tsref + + interface CamtParams { + + // IBAN managed by the running Sandbox, for which + // the Camt.053 response is going to be generated. + iban: string; + + // The Camt type to return. Only '53' is allowed + // at this moment. + type: number; + } + + **Response** + + The expected Camt.053 document. + + .. http:get:: /admin/payments Return the list of *all* the payments known by the sandbox. -- cgit v1.2.3