search

trax-project / trax2-starter-lrs

GNU General Public License v3.0
30 stars 19 forks source link

Installer la v 2.0.4 avec git clone #32

Open sloopint opened 7 months ago

sloopint commented 7 months ago

Bonjour Sébastien,

Je cherche à installer TRAX 2.0.4 sur un sous-domaine tournant sous PHP 8.0. Quand je passe dans le terminal la commande git clone https://github.com/trax-project/trax2-starter-lrs traxlrs, c’est la dernière version (2.1) qui veut s’installer d’office. Comment faire pour récupérer la v 2.0.4 ? J’ai aussi essayé simplement de téléverser la version 2.0.4 zippée dans le sous-domaine en question avant de passer les commandes cd traxlrs puis composer install et de faire la suite de la procédure. Cela semble marcher jusqu'au moment où j'appelle la page de login. Elle reste sur fond violet, le panneau permettant de se loguer ne s'affiche pas. Merci de m'indiquer un moyen plus propre de procéder. Cordialement,

Dominique

sfraysse commented 7 months ago

git clone --single-branch --branch v2.0.4 https://github.com/trax-project/trax2-starter-lrs traxlrs

sloopint commented 7 months ago

Merci, ça marche comme convenu ! Par contre, si je fais (j'aurais besoin aussi de la version 2.0.0) git clone --single-branch --branch v2.0.0 https://github.com/trax-project/trax2-starter-lrs traxlrs , là j'obtiens une erreur...

sfraysse commented 7 months ago

C'est parce que la branche v2.0.0 n'existe pas, seule la branche 2.0.4 a été préservée. Pourquoi souhaitez-vous installer la v2.0.0 ? Je recommanderais d'installer la dernière version, à savoir 2.1, sauf si vous avez une contrainte de version PHP comme cela semble être le cas. Notez que PHP 8.0 est obsolète et ne reçoit plus de patch de sécurité.

sloopint commented 6 months ago

Bonjour Sébastien,

Je reviens vers vous après quelques tests. Hélas, je ne suis pas parvenu à mes fins. J’ai bien conscience qu’il faut privilégier la v 2.1 et donc je vous expose mon problème. J’ai installé TRAX v 2.0.0, v 2.0.4 et v 2.1 dans des sous-domaines. L’installation s’est déroulée normalement. Je parviens donc à envoyer des données xapi vers les trois versions de TRAX, à les voir dans la base de données et dans le tableau de bord de TRAX. Quand je sélectionne PHP 8.0 dans le panel de mon hébergeur, je parviens à récupérer ces données pour en tirer des graphiques et une Datatable (plugin de jquery)… mais uniquement avec TRAX v 2.0.0. En revanche, ça coince avec la v 2.0.4. Quand je passe à PHP 8.1 ou PHP 8.2 pour utiliser TRAX v 2.1, je récupère bien les statements dans ma Datatable. Par contre, même problème que pour la v 2.0.4 avec les graphiques. La console du navigateur me renvoie l’erreur suivante :

Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://www.mon-sous-domaine.comhttps//www.mon-sous-domaine.com/trax/api/code-alphanumérique-du-endpoint/xapi/std/statements?before%5Bid%5D=14456&limit=1000. Raison : échec de la requête CORS. Code d’état : (null).

J’ai poussé la limite à 1000 statements mais ça ne change rien si j’enlève ce paramètre dans mon instruction fetch. Je vous remercie de bien vouloir me mettre sur la piste.

sfraysse commented 6 months ago

Bonjour Dominique,

Une question préliminaire : utilisez-vous l'édition Starter ou Extended ?

Si je résume, avec la version 2.1, vous parvenez à tirez vos données pour votre Datatable, mais pas pour votre graphique. La requête pour votre graphique est bloquée par la politique CORS, alors que la requête pour votre Datatable ne l'est pas. C'est bien ça ?

Il faudrait comparer vos requêtes, y compris leurs entêtes, pour voir ce qui diffère et provoque le blocage de la seconde. CORS concerne l'accès à un serveur depuis un domaine ou sous-domaine différent.

sloopint commented 6 months ago

Bonjour Sébastien,

Désolé pour cette réponse tardive. J’ai des semaines chargées.

1/ J’utilise bien la version Starter. (J’ai noté qu’avec la version Extended, il était possible de stocker les données xapi sur Elasticsearch. Est-ce que ce pourrait être un moyen d’améliorer significativement l’efficacité des requêtes pour la lecture des données sans passer par la mise en place d’une architecture CQRS ?)

2/ Vous résumez bien. Ce que je ne comprends pas, c’est que tout fonctionne sous PHP 8.0 avec la v.2.0.0. C’est quand je passe sous PHP 8.1 avec la v. 2.1 que la requête de mes graphiques m’envoie une erreur CORS. (C’est pourquoi je voulais tester en installant TRAX v. 2.0.0 sur un sous-domaine tournant avec PHP 8.0 et en laissant mon appli web en PHP 8.1. Mon hébergeur me permet de faire cela.)

3/ Le problème, c’est que ce ne sont pas les mêmes requêtes. (GET pour la Datatable et FETCH pour les graphiques.) Je vais poursuivre les recherches et vous tiens au courant.

sfraysse commented 6 months ago

Bonjour Dominique,

Est-ce que ce pourrait être un moyen d’améliorer significativement l’efficacité des requêtes pour la lecture des données sans passer par la mise en place d’une architecture CQRS ?

Dans une certaine mesure car Elasticsearch est optimisé pour du requêtage complexe avec un bon niveau de performances et à grande échelle. Maintenant, ça dépend ce que vous voulez faire de vos données. Le passage par des phases de transformation reste la plupart du temps nécessaire. Cette approche vaut aussi sous Elasticsearch sous le concept de "Transform" : https://www.elastic.co/guide/en/elasticsearch/reference/current/transform-overview.html

avec la v. 2.1 que la requête de mes graphiques m’envoie une erreur CORS

A priori l'implémentation des requêtes CORS n'a pas changé avec la v2.1 (classe \Trax\Auth\Middleware\CorsMiddleware). Il y a une dépendance, mais elle ne semble pas avoir d'impact. Elle se base toutefois sur la présence d'une entête Origin. Pour aller plus loin, il me faudrait comparer les entêtes envoyées et reçues dans vos 2 scénarios.

sloopint commented 2 months ago

Bonjour Sébastien,

Je reviens vers vous car je me demande si le problème que j'ai n'est pas en lien avec le bug détecté par sgamidb.

Dans l'erreur mentionnée ci-dessus, l'URL est en effet retournée deux fois : Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://www.mon-sous-domaine.comhttps//www.mon-sous-domaine.com/trax/api/code-alphanumérique-du-endpoint/xapi/std/statements?before%5Bid%5D=14456&limit=1000. Raison : échec de la requête CORS. Code d’état : (null).

Pensez-vous qu'il s'agisse bien de cela ? Si oui, ce bug sera-t-il résolu avant la sortie de Trax v3 Starter ou dans un avenir proche ?

Merci par avance pour votre réponse.

sfraysse commented 2 months ago

Bonjour Dominique,

Dans la mesure où cela est toléré par la Testsuite ADL, je préfère ne pas changer le comportement de la v2 car si je le fais, je risque de casser des implémentations existantes.

C'est donc l'appel de cette URL qui devra être modifié. Pour être compatible dans tous les cas, vérifier sur l'URL more commence par HTTP ou non, de manière à savoir si c'est une URL absolue ou relative, et à l'utiliser en conséquence. La mise en conformité sera faite uniquement sur la v3.

Sébastien