[Harvest / Konnector] Timeout des 8s pour le "LOGIN_SUCESS"

[Crash--]

Aujourd'hui, nous avons une notion côté front (ie Harvest) de "timeout" pour le "login_success". En effet, certains konnecteurs ne sont pas capables de nous donner un "login_success" et donc ils nous donnent un "success" que quand le konnecteur s'est exécuté correctement. Afin de ne pas bloquer les utilisateurs et les interfaces pendant le temps d'execution d'un konnecteur (qui peut être très long lors de la première utilisation par exemple), Harvest part du principe que s'il n'a reçu aucun EVENT (de success ou d'error) au bout de 8s (que le job soit running ou pas cf #748) , il considère que le login est en succès.

Cependant, à cause de la 2FA, cette hypothèse doit être remise en cause, car il n'est pas rare de mettre plus de 8s entre le début du login et la fin (le temps d'aller chercher le code de 2FA etc).

Nous venons d'ajouter à konnector-lib, le fait de pouvoir désactiver le timer (konnectors/libs#575). Mais, ça n'est pas la solution la plus optimale. En effet, amener une notion front "celle du timer" dans un konnecteur n'est pas idéal.

Proposition : Ajouter l'information dans le manifest du konnector que celui-ci sait géré l'event LOGIN_SUCESS. Ainsi le konnecteur n'a pas besoin de dispatcher de dispatcher un event pour désactiver le timer. En lisant le manifeste, Harvest saura que le konnector gère le login_sucess et ne déclenchera pas le timer.

On pourrait ajouter une clé events dans le manifeste pour lister l'ensemble des EVENT que le konnecteur sait gérer par lui-même ?

manifest.konnector:

{
  name: "MyKonnector",
  events: {
    "LOGIN_SUCESS": true
  }
}

Des avis ?

[ptbrowne]

Je n'ai pas l'impression qu'on ait assez de recul pour avoir une clé events, personnellement je ferais juste une clé autoSuccess: false.

[gregorylegarec]

J'aime beaucoup l'idée de la clé events qui est extensible et plutôt agnostique. 👍

Nous n'avons jamais descendu la gestion du LOGIN_SUCCESS jusque dans les konnecteurs puisque ça nous a toujours paru être une logique purement UX/UI.

[doubleface]

Cette clé events serait aussi intéressante pour les captchas du coup et nous laisse pas mal d'ouverture pour la suite. Je vote pour

[edas]

Ca me gêne un peu d'ajouter une métadonnée pour dire "ce connecteur va se comporter comme on aimerait que tous les connecteurs se comportent". Je préférerais voir le fonctionnement inverse et changer les métadonnées des connecteurs qui n'implémentent pas tout ce qu'on attends (ou mieux : les corriger pour qu'ils envoient les bons événements)

[ptbrowne]

Nous n'avons jamais descendu la gestion du LOGIN_SUCCESS jusque dans les konnecteurs puisque ça nous a toujours paru être une logique purement UX/UI.

Perso ca ne me semble pas juste UI/UX, c'est intéressant aussi par exemple pour les métriques, si on a une erreur de connecteur, c'est intéressant de savoir à quelle étape du connecteur on en est (login / récupération des données).

[ptbrowne]

Cette clé events serait aussi intéressante pour les captchas du coup et nous laisse pas mal d'ouverture pour la suite.

As tu un peu plus de données sur l'utilisation de cette clé, un cas d'usage ? Effectivement events paraît agnostique et générique, perso je serais sûreemnt pour mais j'aimerais bien avoir des cas d'usages un peu plus nombreux et précis. Est ce qu on pourrait les lister dans cette PRs ?

[gregorylegarec]

Perso ca ne me semble pas juste UI/UX, c'est intéressant aussi par exemple pour les métriques, si on a une erreur de connecteur, c'est intéressant de savoir à quelle étape du connecteur on en est (login / récupération des données).

Je me suis mal exprimé, je parlais du timeout de LOGIN_SUCCESS, celui qui permet de simplement supposer qu'on est logué, côté front. En effet le LOGIN_SUCCESS a tout son sens côté konnector, y compris pour les metrics.

[Crash--]

@edas Si c'est au konnecteur de dire LOGIN_SUCESS quid des OAuth ? Vu que le Callback arrive sur une instance particulière de la stack qui redirige (actuellement) sur la Home. Ce serait donc à la Home / Harvest de dispatcher un LOGIN_SUCESS et non au konnecteur ?

[edas]

Je n'avais pas pensé aux connecteurs OAUTH, effectivement