Erreur accès à TaxHub #261
Comments
|
Dans les logs que tu as partagé, c'est toi qui a remplacé par "mondomaine.fr" ? |
|
oui oui, on sait jamais ^^ |
|
J'ai testé sur un Google Pixel Android 14 et j'ai le même problème... |
|
Bonjour, Même souci de mon coté, je prévoyais d'ouvrir un ticket ce jour. Je vais creuser un peu mais je me demande si c'est pas un probleme avec les sous-domaines, j'ai l'impression que sur l'instance de démo avec un /taxhub ca fonctionnait sans souci. Je vérifie et fais un retour, mais effectivement je suis bloqué pour le déploiement de la 2.7 sur 2 de mes instances, faute de tests des RC en amont sur mes instances (je plaide coupable !) |
|
Est-ce qu'on peut télécharger une dernière version sans avoir fait les changements dans la table t_mobile_app pour la tester ? |
|
Bonjour, |
|
@sgrimault de mon coté j'ai l'impression que mes API sont bonnes, mais je ne sais pas sur quelle API il bloque. La dernière route interrogée avant le fail 15:48:26.506 INFO: [fr.geonature.datasync.api.ClientKt] --> GET https://taxhub.mondomaine.fr/api/taxref?orderby=cd_nom&limit=10000&page=1 Est bien accessible dans mon cas. @MoulinZ : la table t_mobile_appsne sert qu'a déclencher la mise à jour manuellement, elle ne gere pas les downgrade. Et il vaut mieux tester sur un mobile et s'assurer que tout est OK en prod avant de déclencher les mises à jour sur tous les terminaux en modifiant cette table |
|
je précise que la route en question https://taxhub.mondomaine.fr/api/taxref?orderby=cd_nom&limit=10000&page=1 est bien accessible dans mon cas également, elle ne fail que sur le mobile (et sur les différents terminaux c'est bien cette route là qui fail). Pour ce qui est du certificat, il est généré avec certbot et n'a jamais posé de problème. Je l'ai regénéré pour être sûr, mais ça ne change rien. |
|
Sans doute pas accessible en dehors de votre infrastructure, car de mon coté je ne peux pas y accéder : |
|
Donnez les bonnes URL car sinon on ne peut rien tester. Mais d'après les différents retours de tests, je pense que ces instances sont OK et qu'il y a bien un truc qui coince au niveau de la 2.7. |
|
Oui c'est plus simple, voici la bonne URL qui fonctionne : https://taxhub-saisie.reserves-naturelles.org/api/taxref?orderby=cd_nom&limit=10000&page=1 |
|
L'erreur remontée est très clair : Je pense qu'il doit y avoir une redirection HTTPS vers HTTP quelque part et en version "release", l'application refuse toute communication HTTP non chiffrée. Je n'avais pas tilté que vous avez caché la vraie URL... 😅 |
|
Test rapide via cURL : curl -k -v https://taxhub-saisie.reserves-naturelles.org/api/taxref?orderby=cd_nom&limit=10000&page=1
Trying 51.159.198.138:443...
Connected to taxhub-saisie.reserves-naturelles.org (51.159.198.138) port 443
ALPN: curl offers http/1.1
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_AES_256_GCM_SHA384
ALPN: server accepted http/1.1
Server certificate:
subject: CN=tax...
start date: Jul ...
expire date: Oct...
issuer: C=US; O=...; CN=R10
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
using HTTP/1.1
GET /api/taxref?orderby=cd_nom HTTP/1.1
Host: taxhub-saisie.reserves-naturelles.org
User-Agent: curl/8.4.0
Accept: */*
>
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
old SSL session ID is stale, removing
< HTTP/1.1 308 PERMANENT REDIRECT
< Date: Wed, 17 Jul 2024 09:35:44 GMT
< Server: gunicorn
< Content-Type: text/html; charset=utf-8
< Content-Length: 329
< Location: http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom
< Vary: Cookie
<
<!doctype html>
<html lang=en>
<title>Redirecting...</title>
<h1>Redirecting...</h1>
<p>You should be redirected automatically to the target URL: <a href="http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom">http://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom</a>. If not, click the link.
...C'est donc bien un problème de redirection. |
|
Ok merci pour ces infos. Mais dans ce cas d'où vient le problème ? et pourquoi ça ne posait pas de problème avec la version 2.6 ? Voici mon fichier taxhub.conf : Et le fichier généré par certbot pour le https : |
|
Je confirme que j'ai bien ce souci également sur 2 instances, avec la conf suivante et le ssl : Il faut sans doute aller voir du coté de taxhub :/ |
|
@MoulinZ Le souci ne se posait pas dans la 2.6 , j'imagine que c'est parce que les taxons étaient récupérés différemment et en appelant d'autres routes pour une partie du process. |
|
d'ailleurs autre étrangeté, c'est que cette erreur n'intervient pas sur une route de l'api précédente : |
|
C'est étrange. Dans un navigateur, si je colle l'url en http : https://taxhub-saisie.reserves-naturelles.org/api/taxref/?orderby=cd_nom |
|
En testant sur la commande curl sur l'instance de @DonovanMaillard, on a pas d'erreur de certificat pour le coup, mais quand même une redirection permanente : |
|
@gildeluermoz @MoulinZ J'ai pu trouver une explication possible et une solution avec l'aide de mon ami ChatGPT... Il semble qu'avec la configuration par défaut de TaxHub et Apache, les règles "Location" Proxy et ProxyReverse traitent une partie des requêtes en http avant que les redirections https soient faites. J'ai donc supprimé les règles "Location" de taxhub.conf sur le port 80, pour ne laisser la règle que sur le port 443 (taxhub-le-ssl.conf). En complément, j'ai ajouté les règles suivantes pour s'assurer que la redirection https soit faite avant de passer par le proxy : En faisant ça, j'ai bien une réponse valide sans Location http avec la commande |
|
On vient de regarder avec Théo et Camille, dans les conf par défaut, il y a bien la règle Le souci vient donc des configurations apache "custom" qu'on conserve depuis un certain nombre de versions pour certains, pour gérer nos sous-domaines respectifs. D'ailleurs pour ma part, il manque aussi une autre règle dans mes conf taxhub : Je repartagerai rapidement des conf à jour pour les sous-domaine en me calquant sur les configurations par défaut de geonature sans sous-domaine, mais je me pose sérieusement la question pour ma part de conserver ces sous-domaines. Je pense repasser sur les conf par défaut pour limiter ce genre de soucis et les recherches de bugs associés :) |
|
Bonjour à tous, même erreur de mon côté que celle obtenue par @sgrimault lors de son test de l'api des réserves. curl -k -v https://geonature.cen-isere.fr/taxhub/api/taxref?orderby=cd_nom&limit=10000&page=1Le retour de console évoque : * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=geonature.cen-isere.fr
* start date: Jun 25 01:44:20 2024 GMT
* expire date: Sep 23 01:44:19 2024 GMT
* issuer: C=US; O=Let's Encrypt; CN=R11
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET /taxhub/api/taxref?orderby=cd_nom HTTP/1.1
> Host: geonature.cen-isere.fr
> User-Agent: curl/7.81.0
> Accept: */*En revanche tout semble OK sur la commande : curl -k -v https://geonature.cen-isere.fr/taxhub/api/taxref/regnewithgroupe2Concernant les configurations apache voici ce que j'ai :
ServerName geonature.cen-isere.fr
IncludeOptional /etc/apache2/conf-available/geonature.conf
IncludeOptional /etc/apache2/conf-available/taxhub.conf
IncludeOptional /etc/apache2/conf-available/usershub.conf
ErrorLog "/var/log/apache2/geonature_error.log"
CustomLog "/var/log/apache2/geonature_access.log" combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =geonature.cen-isere.fr
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
ServerName geonature.cen-isere.fr
DocumentRoot /home/geonatureadmin/geonature/frontend/dist
<Directory /home/geonatureadmin/geonature/frontend/dist>
Require all granted
</Directory>
<Location /api>
ProxyPass http://127.0.0.1:8000 timeout=300
ProxyPassReverse http://127.0.0.1:8000
</Location>
IncludeOptional /etc/apache2/conf-available/geonature.conf
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/geonature.cen-isere.fr/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/geonature.cen-isere.fr/privkey.pem
<Location /taxhub>
ProxyPass http://127.0.0.1:5000 retry=0
ProxyPassReverse http://127.0.0.1:5000
</Location>J'ai tenté de modifier le geonature-le-ssl.conf et le taxhub.conf (l'un après l'autre indépendamment) en ajoutant dans les balises RequestHeader set X-Forwarded-Proto "https"
RequestHeader set X-Forwarded-Ssl onMais rien n'y fait ... |
|
Bonjour, As-tu essaye de mettre les RequestHeader après les balises Location dans GeoNature-le-ssl ? Et bien relancé apache2 ensuite ? |
|
En effet placer les |
|
Le problème peut donc se poser également hors contexte de sous-domaines. Pour le souci c'est qu'une partie des règles à gérer se font dans le fichier de conf ssl, donc après génération du fichier par certbot. Il faudra qu'on complète la doc sur ce point, à plus forte raison si le passage en https et la redirection de toutes les requêtes est indispensable pour le mobile. En l'état, il y a donc plusieurs choses sur lesquelles il faut être vigilant.D'abord l'ajout des règles RequestHeader après (et en dehors) des balises Locations, pour s'appliquer à toutes les requetes des applis. Ensuite, que les "include" des fichiers conf-available soit dans le ssl et pas dans le geonature.conf, pour ne pas rediriger les requetes vers les proxy depuis le port 80 visiblement. On a donc un petit travail à faire sur la doc, mais le souci ne repose pas sur l'appli occtax-mobile en elle-même. Je ferme le ticket ici et j'en ouvre un coté taxhub et geonature puisque c'est ces docs là qu'il faudra mettre à jour :) |
|
@DonovanMaillard : merci pour les explications, j'ai rencontré le même souci et cela m'a permis de résoudre le problème ! |
|
Je ré-ouvre car je ne crois pas que cela a été clarifié/tracé côté TaxHub et/ou GeoNature. |
|
Non pas encore, je teste différentes règles et contextes car :
|
Version de l'application
Version d'Occtax-mobile affectée par le bug : 2.7.0
Version de GeoNature utilisée : 2.14.2
Terminal et Version Android
Marque et modèle du terminal : OnePlus 7T
Version d'Android : 12
Description du bug et comportement attendu
Après le passage à OccTax 2.7.0 (depuis 2.6.1), j'ai une erreur dans la synchronisation des données de TaxHub apparemment, d'après les logs.
Ce qui m'étonne c'est que l'accès à la route
api/taxref/regnewithgroupe2pour récupérer les rangs ne semble pas poser de problème, alors que la récupération de l'ensemble des taxons, elle, bloque.C'est probablement un blocage mobile vu le message :
CLEARTEXT communication not permitted by network security policyMais je ne trouve pas comment corriger tout ça... merci pour votre aide !
Logs
The text was updated successfully, but these errors were encountered: