commit 39c6032057132422a16cad8431b6180c37a3d891
parent 0de353ffc774cba2ba22b71d92aaab90dcaa3672
Author: Marcello Stanisci <marcello.stanisci@inria.fr>
Date: Tue, 28 Mar 2017 17:42:53 +0200
review fulfillment page chapter on advanced topics
Diffstat:
2 files changed, 15 insertions(+), 31 deletions(-)
diff --git a/php/doc/tutorial.texi b/php/doc/tutorial.texi
@@ -944,33 +944,17 @@ a URL (the fulfillment URL) that shows the product each time it gets visited (an
of course, only the first time takes the user's money).
@end enumerate
-In order to implement property (1), the frontend needs a way to recall
-what a contract is about (e.g. which product, which price, the
-timestamp, etc.) before proceeding with the actual payment and
-eventually deliver the final product. That is achieved by
-@emph{reconstructing} the contract using the fulfillment page's URL
-parameters@footnote{the fulfillment URL equipped with all the
-parameters is included in the contract}.
-
-In order to implement property (2), the frontend will firstly check
-the state to see if the product claimed among the fulfillment URL
-parameter has been paid; if so, the product is given to the
-customer. Otherwise, the frontend sets the payment as "pending" in the
-state and @emph{executes} it in the wallet. The payment execution is
-performed by returning information needed by the wallet to issue the
-payment. As seen in section @ref{Initiating the payment process},
-this information must include the contract's hashcode (that the frontend
-can compute using the fulfillment URL parameters).
-The hashcode is then used by the wallet to check if that contract has
-already been paid -- for each paid contract, the wallet keeps the used
-coins and retrieves them via the contract's hashcode. In other words,
-if the hashcode is known to the wallet, then it retrieves the associated
-coins from internal DB, and re-issues the payment with them; otherwise,
-it uses new coins to pay, and then stores them in DB using the new hashcode
-as index. Once the pay page receives the payment, it sets the state for
-the payment as "payed". Finally, the wallet points again the browser
-to the fulfillment URL which now delivers the claimed product to the
-customer.
+Both properties are gotten "for free" by the way replayable payments are
+implemented. Since @code{pay.php} simply relays payments to the backend,
+if the latter returns "200 OK", then the frontend delivers what is mentioned
+in the backend's response. Note that along with the "200 OK" response,
+the backend returns the whole proposal associated with the fulfillment
+URL that triggered the payment, so the frontend has all the information
+useful to pick the right product to deliver.
+The "payment" relayed to the backend contains the @emph{order id},
+that allows the backend to perform all the integrity checks on the
+payment.
+This way, the frontend doesn't need any database to replay payments.
@node Instances
@section Instances
diff --git a/php/inline.php b/php/inline.php
@@ -1,18 +1,18 @@
<?php
// This file is in the public domain.
- include 'contract.php';
+ include "order.php";
$order_id = rand(1,90000); // simplified, do not do this!
- $order = make_order($order_id, new DateTime('now'));
+ $order = make_order($order_id, new DateTime("now"));
$response = post_to_backend("/proposal", $order);
$ret = $response["body"];
if (200 != $response["status_code"]) {
$ret = build_error($response,
- "Failed to generate contract",
- $response['status_code']);
+ "Failed to generate proposal",
+ $response["status_code"]);
}
http_response_code(402); // Payment required
