commit 01a8c1581a266d12af0d074c5d31c5dba37d51a5
parent 4d4e4ceb1624e74b68e06e0a9cf4695c9018dfc3
Author: Christian Grothoff <christian@grothoff.org>
Date: Thu, 2 Nov 2023 22:30:25 +0100
adjust to latest implementation changes
Diffstat:
4 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/core/api-challenger.rst b/core/api-challenger.rst
@@ -49,9 +49,9 @@ particular address. However, asking a user to prove access to a particular
address can be expensive as it may involve sending an SMS or even postal mail
depending on the type of address. Thus, challenger does not allow a user
agent to begin an address validation process without prior approval by a
-registered client. Thus, the process begins with a ``/setup`` request where a
+registered client. Thus, the process begins with a ``/setup/$CLIENT_ID`` request where a
client requests challenger to begin an address validation request. The
-``/setup`` response contains a ``nonce`` which is then used to construct the
+``/setup/$CLIENT_ID`` response contains a ``nonce`` which is then used to construct the
URL of the endpoint to which the client must redirect the user-agent to begin
the address validation and authorization process.
@@ -327,6 +327,17 @@ Info
.. ts:def:: ChallengerInfoResponse
interface ChallengerInfoResponse {
+ // Validation status.
+ status: "success";
+
+ // Details about the validation.
+ data: ChallengerInfoData;
+
+ }
+
+ .. ts:def:: ChallengerInfoData
+
+ interface ChallengerInfoData {
// Address that was validated.
address: string;
diff --git a/manpages/challenger-admin.1.rst b/manpages/challenger-admin.1.rst
@@ -19,7 +19,9 @@ Synopsis
[**-h** | **--help**]
[**-L** *LOGLEVEL* | **--log=**\ \ *LOGLEVEL*]
[**-l** *FILENAME* | **--logfile=**\ \ *FILENAME*]
-[**-v** | **--version**] CLIENT_URL
+[**-q** | **--quiet**]
+[**-v** | **--version**]
+CLIENT_URL
Description
@@ -48,7 +50,10 @@ Its options are as follows:
**-l** *FILENAME* \| **--logfile=**\ \ *FILENAME*
Configure logging to write logs to *FILENAME*.
-**-v** \| **–version**
+**-q** \| **–-quiet**
+ Be less verbose in the output. Useful in shell scripts.
+
+**-v** \| **–-version**
Print version information.
diff --git a/manpages/taler.conf.5.rst b/manpages/taler.conf.5.rst
@@ -287,7 +287,7 @@ KYC_OAUTH2_VALIDITY
Duration (e.g. "12 months") of the validity of the performed KYC check. Can be "forever".
KYC_OAUTH2_AUTHORIZE_URL
- URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is where the exchange will redirect the client to begin the authorization process. Example: "http://localhost:8888/oauth/v2/authorize". To use the plugin in combination with the Challenger service's ``/setup`` step, append "#setup", thus "https://challenger.example.com/authorize#setup". Here, "#setup" is not a fragment but merely a hint to the logic to determine the full authorization URL via the ``/setup`` handler.
+ URL of the OAuth2 endpoint to be used for KYC checks. The authorize URL is where the exchange will redirect the client to begin the authorization process. Example: "http://localhost:8888/oauth/v2/authorize". To use the plugin in combination with the Challenger service's ``/setup`` step, append "#setup", thus "https://challenger.example.com/authorize#setup". Here, "#setup" is not a fragment but merely a hint to the logic to determine the full authorization URL via the ``/setup/$CLIENT_ID`` handler.
KYC_OAUTH2_TOKEN_URL
URL of the OAuth2 endpoint to be used for KYC checks. This is where the server will ultimately send the authorization token from the client and obtain its access token (which currently must be a "bearer" token). Example: "http://localhost:8888/oauth/v2/token" (or just "/token")
diff --git a/taler-challenger-manual.rst b/taler-challenger-manual.rst
@@ -423,7 +423,7 @@ three options from the previous section, but also the authorization, token and
info endpoints. For Challenger, these are ``/authorize``, ``/token`` and
``/info``. However, the ``/authorize`` endpoint is special, as it is actually
``/authorize/$NONCE`` where ``$NONCE`` is a nonce that must be first requested
-by the client using the ``/setup`` endpoint!
+by the client using the ``/setup/$CLIENT_ID`` endpoint!
..note::
@@ -433,7 +433,7 @@ by the client using the ``/setup`` endpoint!
validation could be expensive.
Thus, to generate the authorization URL, a client must first POST to
-``/setup`` using their client secret in an ``Authorization: Bearer $SECRET``
+``/setup/$CLIENT_ID`` using their client secret in an ``Authorization: Bearer $SECRET``
HTTP header to obtain a fresh ``$NONCE``.
In the GNU Taler exchange configuration, this is indicated by appending
