Prototype de GVA

[elois]

@elois

Il semble que async_graphql n’inclus pas les APQ, après je peux toujours le développer moi-même par-dessus, mais c’est pas dans mes priorités…

En fait si, ce n’est pas suffisamment mis en avant dans leur doc, mais il y a bien une extension APQ : ApolloPersistedQueries in async_graphql::extensions::apollo_persisted_queries - Rust

Je peux l’activer si ça vous semble pertinent, encore faut-il que les clients s’en servent

[ManUtopiK]

@elois

c’est aux développeurs de ses clients Ğ1 de m’indiquer de quoi ils ont besoin

Là je ne comprends pas le but de tes messages, je n’arrive pas à identifier un besoin derrière

Oui, désolé. J’ai eu des idées qu’il faut que je test avant de m’emballer…

Génial pour APQ ! Ben c’est tiptop async_graphql ! Voilà, il suffit d’en parler
Pas besoin de l’activer pour l’instant, mais c’est bon à savoir !

[kimamila]

@elois

Ma priorité étant que GVA permettent d’optimiser les clients Ğ1 (Cesium v2, Ğecko, Tikka, etc), c’est aux développeurs de ses clients Ğ1 de m’indiquer de quoi ils ont besoin pour que les traitements soient plus optimisés de leur côté.

J’utilise également activement la librairie cliente Apollo. Effectivement le cache nécessite de reconnaître une partie des objets JSON, pour mettre à jour les éléments déjà chargés par d’autres requêtes.
Dans les serveurs graphql que j’ai en production, au boulot, on se sert du “__typename” et aussi d’un id. Mais l’un comme l’autre peuvent être surchargé.

En fait, le problème de fond est de pouvoir distinguer un objet JSON, dans une grappe de donnée reçue. Il faut un déterminant pour qu’une gestion de cache puisse être agnostique a la requête.
A voir ce qu’on peut définir, donc, comme clef technique de cache.
Merci @ManUtopiK de soulever ce problème.

[ManUtopiK]

@kimamila

En fait, le problème de fond est de pouvoir distinguer un objet JSON, dans une grappe de donnée reçue. Il faut un déterminant pour qu’une gestion de cache puisse être agnostique a la requête.

C’est ça ! Tu as compris ! Et résumé en 2 lignes en +
Ouf, j’avais peur d’avoir fait du bruit pour rien…

Ok, on avance. Un autre problème que je n’ai pas résolu encore, c’est la possibilité de merger 2 schémas Graphql (ou remote joins ou schema stitching). C’est une porte d’entrée vers une architecture micro-services.

Soit ma bdd avec ce schéma :

User {
    id: uuid!
    mail: String!
    myCustomData: String
    ...
    pubkey: String
}

L’idée est d’utiliser la pubkey comme référence pour récupérer les données de GVA et mes données en une seule requête, avec comme relationships entre ma bdd et GVA : user.pubkey = idty.pubkey et/ou user.pubkey = balance.PkOrScriptGva.

Et hop ! En une requête j’ai tout :

query fetchUser($id: uuid!) {
  id
  mail
  gva {
    idty {
      username
      isMember
    }
    balance {
       amount
    }
  }
}

Sauf, que je n’y arrive pas Je ne peux pas merger l’api GVA avec mon api, car mon pubkey est de type String et pas de type pubkey ou PkOrScriptGva. En tout cas, avec Hasura, je n’ai pas réussi à le faire alors qu’ils sont pourtant compatibles Apollo Federation.

@elois Je ne demande rien pour l’instant ! C’est juste pour faire remonter mon expérience. Il faut que je fasse d’autres tests…

[poka]

@tuxmain est-ce que tu crois que tu pourrais ajouter à la commande idty GVA l’arguement username pour rechercher une pubkey par username ? J’en ai vraiment besoin

[tuxmain]

Pour rechercher comment ? Je peux faire facilement « commençant exactement par » (ou insensible à la casse, si besoin), mais « contenant » ou en tolérant des fautes, c’est plus compliqué. (c’est faisable mais ça prendra trop de temps à répondre)

Tu veux seulement la pubkey, ou aussi les autres champs de idty, ce qui peut économiser une requête ?

[poka]

@tuxmain

Tu veux seulement la pubkey, ou aussi les autres champs de idty, ce qui peut économiser une requête ?

Bah tous les champs tant qu’à faire ?

Juste qui match le username exact.
Le reste, c’est si tu as envie de chiader le truc

[tuxmain]

Fait : idty_by_username (!3) · Merge requests · nodes / rust / modules / duniter-gva · GitLab

Ça ne fait que le match exact, et ça renvoie exactement les mêmes données que idty(pubkey). (et j’ai ajouté un champ pubkey dans la réponse)

C’est plutôt à des services comme Cesium+ de fournir une recherche avancée, et pour les utilisateurs un tel service serait plus intéressant que GVA qui ne saurait faire que les majuscules et le « commence par », donc je ne l’ai pas fait.

[elois]

@tuxmain

C’est plutôt à des services comme Cesium+ de fournir une recherche avancée, et pour les utilisateurs un tel service serait plus intéressant que GVA qui ne saurait faire que les majuscules et le « commence par », donc je ne l’ai pas fait.

Peut tu aux moins le rendre insensible à la casse en faisant un to_uppercase() avant la comparaison ?

[tuxmain]

Ah mais ça veut dire ajouter tout le bazar pour renvoyer une liste !

Et si la taille max est 100 ça veut dire qu’on peut renvoyer jusqu’à 2^100 résultats, donc il faut paginer.

Et il y a plusieurs manières pour la db : username(insensible) -> HashMap<username(sensible), pubkey> ou username(insensible)+username(sensible) -> pubkey

Il faudrait aussi ajouter un champ case_sensitive vrai par défaut.

Mais je me disais que si cette fonctionnalité est utilisée, c’est forcément pour la recherche par un utilisateur, or un utilisateur voudrait un truc plus sophistiqué (regex, Levenstein, soundex…). Cesium+ ne fait pas encore aussi complet mais fait déjà mieux que juste la casse. Donc je doute de l’utilité d’une telle fonctionnalité.

[elois]

@tuxmain

Donc je doute de l’utilité d’une telle fonctionnalité.

Ben c’est demandé par @kimamila l’insensibilité à la casse donc si c’est utile.

@tuxmain

Et il y a plusieurs manières pour la db : username(insensible) -> HashMap<username(sensible), pubkey> ou username(insensible)+username(sensible) -> pubkey

Il faudrait aussi ajouter un champ case_sensitive vrai par défaut.

Pas besoin de faire aussi compliqué, keep it stupid simple: stocke la clé en uppercase et passe par un set (key: username(uppercase) ++ pubkey, value: ()).

Puis récupère les vrais usernames dans BcV2.

Le plus simple c’est de remonter une liste tout le temps puis de filtrer au niveau du resolver si on veut que ça match exact.

[tuxmain]

Ah en effet je viens de voir que Cesium demande à Duniter pour la recherche…

Donc pour éviter de faire une régression il faudrait aussi gérer le « commence par ».

Edit: UPPERCASE ça me fait trop penser à Windows, ses API et FAT32… s’il n’y a pas de raison particulière je préfère lowercase.

[elois]

@tuxmain

Donc pour éviter de faire une régression il faudrait aussi gérer le « commence par ».

Ça pareil tu peux le gérer avec un filtre dans le résolver, ça évite de complexifier la db

@tuxmain

s’il n’y a pas de raison particulière je préfère lowercase.

Oui qu’importe c’est équivalent

[poka]

@elois

L’anti-spam limite à 40 requêtes par tranche de 20 secondes, ça me semble suffisant pour un usage d’un utilisateur final, on pourra toujours augmenter un peu si l’on constate par l’expérience que c’est trop restrictif.

L’anti-spam de GVA est beaucoup trop sévère, si l’on pagine un peu trop vite les pages d’historique d’un profil, on se fait ban assez vite.

Je ne trouve plus comment régler la whitelist dans le conf.json, ceci ne fonctionne pas:

 "gva": {
  "whitelist": [
   "127.0.0.1",
   "86.201.xx.xx"
  ] 
 }

Cela non plus:

 "dos": {
  "whitelist": [
   "127.0.0.1",
   "86.201.12.250"
  ],

Je n’ai pas de champ gva dans cette conf par défaut il s’agit d’un noeud docker, dont les paramètres du noeud sont passés en variables d’environnement via le docker-compose.

Quelqu’un saurait comment éditer cette whitelist, ou bien assouplir les valeurs de l’anti-spam, ou bien carrément le désactiver ?

[tuxmain]

Dans le mien j’ai :

 "gva": {
  "enabled": true,
  "ip4": "127.0.0.1",
  "ip6": "::1",
  "path": "gva",
  "port": 30901,
  "subscriptionsPath": "gva-sub",
  "whitelist": [
   "::1",
   "127.0.0.1"
  ]
 }

Ça semble cohérent avec le code source (conf/src/lib.rs) :

pub struct GvaConf {
    pub enabled: bool,
    #[serde(default = "ip4_default")]
    pub ip4: Ipv4Addr,
    pub ip6: Option<Ipv6Addr>,
    #[serde(default = "port_default")]
    pub port: u16,
    #[serde(default = "whitelist_default")]
    pub whitelist: Vec<IpAddr>,
    // [...]
}

[poka]

Cela ne fonctionne pas dans un nœud docker.

Est-ce que tu sais où et comment changer les valeurs de ce filtre ?
Réglé ainsi, cela rends GVA inutilisable en condition réelle.

[vit]

Si des variables d’environnement ne sont pas prises en compte dans docker, peut-être voir avec @Pini.

[Pini]

Sur la branche dev on trouve mention dans la doc [1] d’une variable DUNITER_GVA_WHITELIST, mais celle-ci n’apparaît nulle part dans le code.

[1] doc/use/conf_env_var.md

Edit - D’ailleurs pratiquement aucune des variables DUNITER_GVA_* référencées dans la doc n’existe dans le code.

[poka]

On ne peut pas passer une tableau en variable d’environnement:

ERROR: The Compose file './jinja-compose.yml' is invalid because:
services.duniter.environment.DUNITER_GVA_WHITELIST contains ["127.0.0.1", "::1"], which is an invalid type, it should be a string, number, or a null

Il aurait fallut attendre une suite de string séparé par des virgules, et split la chaine ainsi…

---

De toute manière ce qui m’intéresse, c’est surtout pour changer les valeurs de ce filtre anti-spam.

Je constate qu’il n’est pas réglé comme indiqué par elois, il suffit d’envoyer 5 requêtes successives pour se faire ban.

J’aimerais augmenter cette valeur.

$ while true; do jaklis currentUd 2>/dev/null || echo error; sleep 0.5; done
1042
1042
1042
1042
1042
1042
error
error
error
error
error
error
error
error

$ while true; do jaklis currentUd 2>/dev/null || echo error; sleep 1; done
1042
1042
1042
1042
1042
error
1042
1042
1042
1042
1042
error
error
error
error
error
error

$ while true; do jaklis currentUd 2>/dev/null || echo error; sleep 2; done
1042
1042
1042
1042
1042
error
1042
1042
1042
1042
1042
error
1042
1042
1042
1042
1042
error
error
error
error
error
error
error
error
error
error
error
error
error
error
error

(les error ici sont des bans IP).

Un utilisateurs qui scroll trop vite l’historique d’un profil sur Gecko se fait ban assez facilement.

[Pini]

@poka : Peux-tu me pointer la version des sources que tu utilises ? Car comme dit plus haut, je ne trouve aucune référence à cette variable sur la branche dev.