Utilisation clé API

Bonjour,
Je viens de recevoir ma clé API. Comment puis-je résoudre l'erreur de révocation de certificat.Voir détail ci-dessous.
Je suis sous windows 10 et Mozilla Firefox (à jour).

Contexte: Je suis dans une fenêtre de lignes de commandes Windows(après cmd.exe) en mode administrateur (même erreur idem mode utilisateur)
C:WINDOWSsystem32>curl --version
curl 7.79.1 (Windows) libcurl/7.79.1 Schannel
Release-Date: 2021-09-22
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets

Commande en échec (Récupération de la liste des traces)
C:WINDOWSsystem32>curl -X GET -H "Authorization: Bearer ************" "https://www.visugpx.com/api/activities?activity=rp&flux=1"
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de révocation n'a pas pu vérifier la révocation du certificat.

En rajoutant --ssl-no-revoke -v à la fin de la commande, j'obtiens ce qui suit :
C:WINDOWSsystem32>curl -X GET -H "Authorization: Bearer ************" "https://www.visugpx.com/api/activities?activity=rp&flux=1" --ssl-no-revoke -v
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying 109.234.165.84:443...
* Connected to www.visugpx.com (109.234.165.84) port 443 (#0)
* schannel: disabled automatic use of client certificate
* schannel: ALPN, offering http/1.1
* schannel: ALPN, server accepted to use http/1.1
> GET /api/activities?activity=rp&flux=1 HTTP/1.1
> Host: www.visugpx.com
> User-Agent: curl/7.79.1
> Accept: */*
> Authorization: Bearer ***************************
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Tue, 13 Dec 2022 16:56:48 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Powered-By: PHP/7.2.34
< Server: o2switch-PowerBoost-v3
<
{"ERROR": "INVALID ACCESS_TOKEN"}* Connection #0 to host www.visugpx.com left intact

Merci.
Cordialement.

[Edité par Admin le 13/12/2022 18:36] Masquage de la clé

Bonjour, il y a visiblement un soucis avec votre connexion qui doit passer par un serveur proxy qui n'est pas configuré https ? Essayez de taper "netsh winhttp show proxy" dans l'invite de commande pour voir, ou la requête de base (sans --ssl-no-revoke) avec -v pour voir s'il contacte bien le site en https.

La réponse retournée est {"ERROR": "INVALID ACCESS_TOKEN"} car le token n'est pas correct, conformément à la doc :

Chaque requête doit être signée dans l'entête (header) de la demande, au choix :

Avec un paramètre "cle:" suivi de la clé vous avez récupéré dans votre profil (si vous souhaitez seulement accéder à votre propre compte). Ce paramètre donne un accès en lecture/ecriture.
Avec une autorisation de type "Authorization: Bearer" suivi du token d'accès associé à l'utilisateur tiers (Documentation Oauth2) (pour un accès au comptes d'utilisateurs tiers). Un scope est associé au token d'accès qui permet un accès en lecture uniquement, ou en lecture/écriture.

Si vous avez récupéré le clé dans votre profil, vous pouvez uniquement accéder à vos propres traces et la syntaxe est

curl -H "cle: ************" "https://www.visugpx.com/api/activities?activity=rp&flux=1"

Le "-X GET" est même inutile car c'est le mode par défaut

Le header "Authorization: Bearer" est seulement utile pour récupérer des traces d'utilisateurs tiers via une authentification Oauth2 décrite dans la doc.

Bonjour,
Merci pour votre réponse rapide hier.
Voici le résultat pour les deux tests suggérés :

C:WINDOWSsystem32>netsh winhttp show proxy

Paramètres de proxy WinHTTP actuels :

Accès direct (sans serveur proxy).


C:WINDOWSsystem32>curl -H "cle: QkXXXXXXXXXXXXXXXXPK" "https://www.visugpx.com/api/activities?activity=rp&flux=1" -v
* Trying 109.234.165.84:443...
* Connected to www.visugpx.com (109.234.165.84) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de révocation n'a pas pu vérifier la révocation du certificat.
* Closing connection 0
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - La fonction de révocation n'a pas pu vérifier la révocation du certificat.

Effectivement, il semblerait que le problème soit situé au niveau de l'environnement/paramétrage du PC windows.
Mais je ne sais pas quoi faire pour corriger le pb.

Comme j'ai trouvé une porte fermée (Windows), J'ai essayé de passer par une autre (raspberry pi 4 sous debian). Là, le résultat semble plus encourageant. Mais je ne vois toujours pas de liste de traces en retour. Le résultat , on le récupère bien dans l'invite de commande ou dans la fenêtre du terminal qui a transmis la commande ?
Voici le résultat du test :
pi411[AT]raspberrypi🤨 $ curl -H "cle: QkXXXXXXXXXXXXXXXXXPK“ ”https://www.visugpx.com/api/activities?activity=rp&flux=1" -v
* Trying 109.234.165.84:443...
* Connected to www.visugpx.com (109.234.165.84) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=visugpx.com
* start date: Oct 27 11:59:36 2022 GMT
* expire date: Jan 25 11:59:35 2023 GMT
* subjectAltName: host "www.visugpx.com" matched cert's "www.visugpx.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55674d1ce0)
> GET /api/activities?activity=rp&flux=1 HTTP/2
> Host: www.visugpx.com
> user-agent: curl/7.74.0
> accept: */*
> cle: QkXXXXXXXXXXXXXXXXXXXXXPK
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Wed, 14 Dec 2022 16:02:36 GMT
< content-type: text/html; charset=UTF-8
< content-length: 0
< x-powered-by: PHP/7.2.34
< server: o2switch-PowerBoost-v3
<
* Connection #0 to host www.visugpx.com left intact

Merci.
Cdt

Bonjour, oui vous devez récupérer le flux dans le terminal en sortie.

Cette histoire de certificat est quand même visiblement bizarre parce que c'est simplement une requête sur une adresse et donc il n'y a pas de raison qu'il y ait un problème alors qu'il n'y en a pas si vous passez par un simple navigateur....

Essayez simplement d'appeler /api/activities (sans les paramètres, peut être que vous n'avez pas de randonnée pédestre déclaré en tant qu'activité dans votre flux ?)

Pour ma part, depuis la console windows tout est OK.

Re,
Effectivement, je n'ai pas d'activité dans l'onglet Mes activités. Je veux simplement récupérer la liste des traces dans l'onglet Mes traces (20 circuits environ pour l'instant)
Dans la doc API J'ai lu :
/api/activities
Récupère la liste des traces
Je n'ai pas bien compris ce que vous entendez dans la notion d'activité. On peut considérer cela comme les traces courantes ou les traces du moment ?

Merci.
Cordialement

Comme son nom l'indique, une activité est ... une activité 😜
C'est à dire que vous avez physiquement parcouru l'itinéraire ! Ça permet de différentier les traces de préparation des traces réellement suivies !

Pour déclarer une trace en tant qu'activité, il faut qu'elle soit horodatée (qu'elle contienne des dates), et que vous ayez coché la case "Activité" lors de son enregistrement.

Les activités apparaissent en plus dans l'onglet "Activités" et vous permettent en plus d'avoir quelques statistiques mensuelles (durées, dénivelé, distance, ...)

Cdlt

Bonjour,
Merci pour l'aide.

Cela fonctionne correctement maintenant. 👍
La commande ci-dessous me permet bien de récupérer toutes mes traces sur Debian :
curl -H "cle: QkXXXXXXXXXXXXXXXXPK" "https://www.visugpx.com/api/activities?activity=rp"

Sur Windows, il faut rajouter l'option --insecure pour pallier le problème de la révocation du certificat.

Pour les données en retour, cela serait super de rajouter (si cela est possible) un saut de ligne (CR/LF) entre chaque trace de façon à faciliter le reformatage derrière (présentation des traces sous forme de table ou tableau).
Cordialement 😄

Bonjour, sur VOTRE windows parce que sous le mien tout se passe bien 😜

Comme indiqué dans l'API, les données de sorties sont formatées JSON https://www.visugpx.com/api/get_activities.json , il faut que vous manipuliez du JSON pour afficher ce que vous voulez !