Mise en forme de code: pensez à utiliser les balises [ tcl ] et [ /tcl ] (sans les espaces bien sûr) autour de vos codes tcl afin d'avoir un meilleur rendu et une coloration syntaxique. x


Une fonction qui retourne true si le pseudo est identifié (+r)
#1
Bonjour,

J'essaye de modifier le tapavu.tcl que j'utilise depuis des années afin qu'il accepte les "!tapavu" seulement de la part d'utilisateurs identifiés (+r).

Voici le morceau de code du pub de "!tapavu" que j'voudrais modifier:


tcl
bind pub -|- $tapavu(command)tapavu tapavu:pub:req
proc tapavu:pub:req {nick uhost hand channel arg} {
  if { !isIdentifiedToNs($nick) } { // une fonction à créer isIdentifiedToNs($nick) qui retourne true si l'utilisateur est +r sinon false
     puthelp "NOTICE $nick :04$nick12, je n'accepte les demandes des utilisateurs non-enregistrés."
     return 1
  }
if {$arg == ""} {
  puthelp "PRIVMSG $channel :12Qui ça 04$nick12 ?"
  return 1
}
tapavu:pubreq $nick $uhost $hand $channel $arg 0
}




Comment il faudrait faire pour faire ce genre de fonction ?

Cordialement
  Répondre
#2
Désolé de te le dire, mais ça risque d'être très compliqué: il faut que l'eggdrop fasse un /whois sur l'utilisateur et récupère soit ses modes (pour savoir s'il y a le "r" dedans) soit la notice indiquant que l'utilisateur est enregistré (a priori raw 307 sur bahamut et unreal, je ne sais pas pour les autres ircd). Ou bien interroger directement Nickserv (msg nickserv info xxx).
Donc, tu peux avoir beaucoup de latence entre la commande et sa validation car tu ne sais pas à quelle vitesse le serveur te répondra et selon l'option choisie, tu dois gérer le fait qu'il n'y ait pas de réponse dans un certain temps pour déclarer que la personne n'est pas enregistrée.

En théorie, c'est donc tout à fait possible, en pratique le fonctionnement sera très aléatoire et dépendant de beaucoup de facteurs.
  Répondre
#3
Merci d'avoir expliquer tous les inconvénients avec le whois sur eggdrop.

En fait pour que tout soit plus simple, faudrait faire un tapavu/bseen en JavaScript avec NodeJS, c'est dommage qu'il en n'existe aucun.

Cordialement
  Répondre
#4
NodeJS ? C'est quoi cette idée bizarre ? Et qu'est-ce que ça apporterait de plus ?
Je ne vois même pas ce que tu voudrais concevoir comme ça.
  Répondre
#5
Je sais que le eggdrop 1.9 support petit a petit IRCv3. Si le serveur IRC support aussi le IRCv3 peut-être voir du coté des account-tracking: https://ircv3.net/irc/#account-tracking.

Sinon, si le IRC utilise anope il est possible de demander a Nickserv

https://wiki.anope.org/index.php/NickServ#Status
il me semble que le script : https://scripts.eggdrop.fr/details-Messa...-s107.html utilise cette méthode

ou alors la technique du whois

Avec NODE.JS qui est hors sujet il faudrais voir avec la librairie IRC, en 3 ligne tu connnecte deja le bot sur IRC, et ensuite implanté les fonctions de tapavu mais ton probleme restera le meme pour savoir si l'utilisateur est enregistrer ou non.
  Répondre
#6
salut,,
<troll>
éventuellement avoir le salon en  +R,  probleme reglé :)
</trol>
  Répondre
#7
(18/12/2020, 16:12)cestlemien a écrit : salut,,
<troll>
éventuellement avoir le salon en  +R,  probleme reglé :)
</trol>

Ce n'ai pas con.
  Répondre
#8
re,-salut,

tu pourrais aussi, faire sur une condition uniquement lors de la demande,

je ne fait pas le bout de code, mais ne donne qu'une orientation possible.
bidule etant l'user, robot etant ton eggdrop.

Citation :Bidule !tapavu
robot detecte le bind , et fait une demande à nickserv " msg nickserv info $nick (bidule) "

- nickserv repond que bidule est enregistré , ou pas

- On recupere donc le message,

-de là si nick est register, on repond avec les infos adequat ( via pv ou notice),

- sinon on envoie la notice adequat

********** fin du bout de code ************.

( on peux aussi ajouter un flag si "user" est vu comme pseudo enregistré, et ne pas redemandé l'info a nickserv , ça ajoute donc de lire les flags )


NB:

Ca evite de faire multiples requetes qui ralentissent le server, augmentent la charge du robot on join, et garder l'info en mémoire
A noter que si les services tombent, Evidement ça ne fonctionnera plus dans tous les cas. sauf pour ceux auquel on aura utilisé le system de flag

une base de travail aussi ici : https://forum.eggdrop.fr/nick-non-regist...t-454.html

Bonne année à tous.
  Répondre
#9
(15/12/2020, 16:00)mcdeffice a écrit : Je sais que le eggdrop 1.9 support petit a petit IRCv3. Si le serveur IRC support aussi le IRCv3 peut-être voir du coté des account-tracking: https://ircv3.net/irc/#account-tracking.

Dans le cas où vous avez eggdrop 1.9.x que le serveur IRCD accepte "Account tracking" (IRCv3) et que les options eggdrop de capabilities est activé il devrais etre possible grace a eggdrop de le savoir simplement

car account-notify donne les comptes aux utilisateurs qui change de status,
le extended-join met a jour quand l'utilisateur rejoins un salon

en gros, si dans .status vous avez "Account tracking", "extended-join", "account-notify" eggdrop 1.9 devrais etre capable de vous aidez:

https://github.com/eggheads/eggdrop/blob...me-channel

Code :
getaccount <nickname> [channel]
Returns: the services account name of the nickname if they are logged in, "" otherwise, and an error if the account-notify or extended-join capabilites are not enabled. WARNING: this account list may not be accurate depending on the server and configuration. This command will only work if a server supports (and Eggdrop has enabled) the account-notify and extended-join capabilities, and the server understands WHOX requests (also known as raw 354 responses).

https://github.com/eggheads/eggdrop/blob...me-channel

Code :
isidentified <nickname> [channel]
Returns: 1 if someone by the specified nickname is on the channel (or any channel if no channel name is specified) and is logged in); 0 otherwise

Module: irc


Code :
ACCOUNT (stackable)
bind account <flags> <mask> <proc>

procname <nick> <user> <hand> <account>

Description: triggered when Eggdrop receives an ACCOUNT message. The mask for the bind is in the format "#channel nick!user@hostname.com account" where channel is the channel the user was found on when the bind was triggered, the hostmask is the user's hostmask, and account is the account name the user is logging in to, or "" for logging out. The mask argument can accept wildcards. For the proc, nick is the nickname of the user logging into/out of an account, user is the user@host.com hostmask, hand is the handle of the user (or * if none), and account is the name of the account the user logged in to (or "" if the user logged out of an account).
  Répondre
#10
Beaucoup de "SI".
Je ne sais pas si beaucoup de réseaux sont passés en IRCv3 et eggdrop1.9 est toujours en phase de développement, donc plutôt confidentiel.

McDeffice a écrit :en gros, si dans .status vous avez "Account tracking", "extended-join", "account-notify" eggdrop 1.9 devrais etre capable de vous aidez:
Pas bien d'accord:
Code :
Account tracking: Disabled
  (Missing capabilities: extended-join)
Active CAP negotiations: None

Et pourtant:
Code :
.tcl getaccount CrazyCat
[16:42] tcl: builtin dcc call: *dcc:tcl CrazyCat 12 getaccount CrazyCat
[16:42] tcl: evaluate (.tcl): getaccount CrazyCat
Tcl: CrazyCat
.tcl getaccount Artus
[16:42] tcl: builtin dcc call: *dcc:tcl CrazyCat 12 getaccount Artus
[16:42] tcl: evaluate (.tcl): getaccount Artus
Tcl: Excalibur
Je peux bien avoir l'info renvoyée par NickServ...
  Répondre
#11
(21/01/2021, 17:43)CrazyCat a écrit : Beaucoup de "SI".
Je ne sais pas si beaucoup de réseaux sont passés en IRCv3 et eggdrop1.9 est toujours en phase de développement, donc plutôt confidentiel.

Et oui, beaucoup de "SI", la technique par NickServ a aussi beaucoup de SI. Tous les serveur IRC n'utilise pas forcement ANOPE.
La technique Nickserv et WHOIS peuvent être bien trop couteuses en ressources et en latence (comme tu la dit précédemment) avec un danger de excess flood.

Je ne fait que donner une méthode en plus, il nous a pas été indiquer quel été le IRCD, ni sa version

La liste de IRCD qui prend le support ici : https://ircv3.net/software/servers

Le commit eggdrop qui implante ces fonctions est ici : https://github.com/eggheads/eggdrop/comm...6d1e2d9145


(21/01/2021, 17:43)CrazyCat a écrit :
McDeffice a écrit :en gros, si dans .status vous avez "Account tracking", "extended-join", "account-notify" eggdrop 1.9 devrais etre capable de vous aidez:
Pas bien d'accord:
Code :
Account tracking: Disabled
 (Missing capabilities: extended-join)
Active CAP negotiations: None

Et pourtant:
Code :
.tcl getaccount CrazyCat
[16:42] tcl: builtin dcc call: *dcc:tcl CrazyCat 12 getaccount CrazyCat
[16:42] tcl: evaluate (.tcl): getaccount CrazyCat
Tcl: CrazyCat
.tcl getaccount Artus
[16:42] tcl: builtin dcc call: *dcc:tcl CrazyCat 12 getaccount Artus
[16:42] tcl: evaluate (.tcl): getaccount Artus
Tcl: Excalibur

Peut-être que j'ai mal compris la doc de eggdrop qui précise :
Code :
WARNING: this account list may not be accurate depending on the server and configuration. This command will only work if a server supports (and Eggdrop has enabled) the account-notify and extended-join capabilities, and the server understands WHOX requests (also known as raw 354 responses).

Ce que je comprend c'est que le serveur doit prendre les fonctions "account-notify et extended-join capabilities" et etre activer sur eggdrop


(21/01/2021, 17:43)CrazyCat a écrit : Je peux bien avoir l'info renvoyée par NickServ...

Le rapport avec NickServ la dedans ?! Chacun ses méthodes ... apres si nickserv te convient c'est libre à toi, tonton. Si les condition pour utiliser nickserv et les danger de celle ci te conviens mieux c'est un choix. Il n'empêche qu'il existe d'autres manières avec leurs avantages et leurs inconvenants.

Au lieu de flood nickserv, il sufis aussi de whois alors ... :D

L' Account tracking est peut-être récent dans une certaines mesure, elle existe pour contrer justement certains probleme. Eggdrop l'implante dans son code pour permet d'avoir les informations de manière direct dans une fonction TCL , si les codition sont reunis, il est bien plus simple de faire un

if { [isidentified $nick] } {
....
}

Que commence a faire un WHOIS ou un PRIVMSG, devoir récupérer la réponse, et lancer une proc pour poursuivre .. donc beaucoup de "SI" rien ce perd ..

(15/12/2020, 08:45)CrazyCat a écrit : Désolé de te le dire, mais ça risque d'être très compliqué: il faut que l'eggdrop fasse un /whois sur l'utilisateur et récupère soit ses modes (pour savoir s'il y a le "r" dedans) soit la notice indiquant que l'utilisateur est enregistré (a priori raw 307 sur bahamut et unreal, je ne sais pas pour les autres ircd). Ou bien interroger directement Nickserv (msg nickserv info xxx).
Donc, tu peux avoir beaucoup de latence entre la commande et sa validation car tu ne sais pas à quelle vitesse le serveur te répondra et selon l'option choisie, tu dois gérer le fait qu'il n'y ait pas de réponse dans un certain temps pour déclarer que la personne n'est pas enregistrée.

En théorie, c'est donc tout à fait possible, en pratique le fonctionnement sera très aléatoire et dépendant de beaucoup de facteurs.
1) "ça risque d'être très compliqué"
2) (pour savoir s'il y a le "r" dedans) -> usermode par whois? faut etre ircop ?!
3) soit la notice indiquant que l'utilisateur est enregistré (a priori raw 307 sur bahamut et unreal, je ne sais pas pour les autres ircd) -> SI, si ..
4) Ou bien interroger directement Nickserv (msg nickserv info xxx). -> si les services permettent ...
4.1) beaucoup de latence entre la commande et sa validation
4.2) tu dois gérer le fait qu'il n'y ait pas de réponse dans un certain temps pour déclarer que la personne n'est pas enregistrée.

VS

1) Avoir eggdrop 1.9
2) un IRCD supportant les capabilities
3) utiliser un if dans TCL
  Répondre
#12
Salut,

Sinon pour faire plus simple

Si $nick rejoint whois si +r ok, sinon kick.
C'est plus ou moins le même système que dans un whois de look l'âge requis dans un whois, le raw est juste pas le même.

Ensuite pourquoi ne pas utilisé les logs eggdrops ?

Tu fait une demande l'eggdrop regarde dans le log du canal "qui est quand-même sa fonction de base", et ensuite tu transmet sur le canal tout simplement non ?
Vous interdisez les erreurs, vous empêchez ainsi la victoire.

Ma super kikoo-page loll
  Répondre
#13
(21/01/2021, 20:00)mcdeffice a écrit : Ce que je comprend c'est que le serveur doit prendre les fonctions "account-notify et extended-join capabilities" et etre activer sur eggdrop
(21/01/2021, 17:43)CrazyCat a écrit : Je peux bien avoir l'info renvoyée par NickServ...
Le rapport avec NickServ la dedans ?! Chacun ses méthodes ... apres si nickserv te convient c'est libre à toi, tonton. Si les condition pour utiliser nickserv et les danger de celle ci te conviens mieux c'est un choix. Il n'empêche qu'il existe d'autres manières avec leurs avantages et leurs inconvenants.

Au lieu de flood nickserv, il sufis aussi de whois alors ... :D

Tu n'as effectivement pas tout compris je pense.

Je n'ai pas interrogé NickServ, j'ai utilisé getaccount qui se débrouille comme il veut avec les CAP du serveur. Sauf que mon pseudo n'est pas enregistré auprès des serveurs IRC mais auprès des services. C'est donc l'ensemble ircd + services qui fournit les CAP.
Si tu lis bien mes logs, tu ne trouveras aucun appel à NickServ ou à un script quelconque, je fais juste une demo avec un eggdrop 1.9 sur un serveur en unrealircd-5.x et anope-2.x.

La seule chose que je déclarais fausse, ou pas bien certaine, c'est ta manière de savoir si l'ensemble serveur/eggdrop pouvait utiliser ces fonctionnalités.
  Répondre
#14
salut,
Je me permet d'ajouter qu'il encore que les dits modules aient ete activés par les admins du reseau, ce qui n'est pas fait par defaut il me semble. Et s'ils trouvent que l'utilisateur lambda n'en aura pas l'utilité, il s'abstiendront d'ajouter des modules dont eux n'ont pas l'utilité.
  Répondre
#15
(15/12/2020, 08:45)CrazyCat a écrit : Désolé de te le dire, mais ça risque d'être très compliqué: il faut que l'eggdrop fasse un /whois sur l'utilisateur et récupère soit ses modes (pour savoir s'il y a le "r" dedans) soit la notice indiquant que l'utilisateur est enregistré (a priori raw 307 sur bahamut et unreal, je ne sais pas pour les autres ircd). Ou bien interroger directement Nickserv (msg nickserv info xxx).
Donc, tu peux avoir beaucoup de latence entre la commande et sa validation car tu ne sais pas à quelle vitesse le serveur te répondra et selon l'option choisie, tu dois gérer le fait qu'il n'y ait pas de réponse dans un certain temps pour déclarer que la personne n'est pas enregistrée.

En théorie, c'est donc tout à fait possible, en pratique le fonctionnement sera très aléatoire et dépendant de beaucoup de facteurs.

(22/01/2021, 02:21)cestlemien a écrit : salut,
Je me  permet  d'ajouter qu'il  encore  que les dits modules aient  ete activés par les admins du reseau, ce qui n'est pas fait par defaut il me semble. Et  s'ils trouvent que l'utilisateur lambda n'en aura pas l'utilité, il s'abstiendront  d'ajouter des modules dont eux n'ont pas l'utilité.

les Capabilities dans unrealircd est activé par default sur les nouvelles version. les administrateurs réseaux devrons ajouter set::options::disable-cap dans leurs configurations pour le désactiver. Comme quoi, ce n'ai pas si fou.

(15/12/2020, 08:45)CrazyCat a écrit : Désolé de te le dire, mais ça risque d'être très compliqué: il faut que l'eggdrop fasse un /whois sur l'utilisateur et récupère soit ses modes (pour savoir s'il y a le "r" dedans) soit la notice indiquant que l'utilisateur est enregistré (a priori raw 307 sur bahamut et unreal, je ne sais pas pour les autres ircd). Ou bien interroger directement Nickserv (msg nickserv info xxx).
Donc, tu peux avoir beaucoup de latence entre la commande et sa validation car tu ne sais pas à quelle vitesse le serveur te répondra et selon l'option choisie, tu dois gérer le fait qu'il n'y ait pas de réponse dans un certain temps pour déclarer que la personne n'est pas enregistrée.

En théorie, c'est donc tout à fait possible, en pratique le fonctionnement sera très aléatoire et dépendant de beaucoup de facteurs.

(22/01/2021, 01:15)CrazyCat a écrit :
(21/01/2021, 20:00)mcdeffice a écrit : Ce que je comprend c'est que le serveur doit prendre les fonctions "account-notify et extended-join capabilities" et etre activer sur eggdrop
(21/01/2021, 17:43)CrazyCat a écrit : Je peux bien avoir l'info renvoyée par NickServ...
Le rapport avec NickServ la dedans ?! Chacun ses méthodes ... apres si nickserv te convient c'est libre à toi, tonton. Si les condition pour utiliser nickserv et les danger de celle ci te conviens mieux c'est un choix. Il n'empêche qu'il existe d'autres manières avec leurs avantages et leurs inconvenants.

Au lieu de flood nickserv, il sufis aussi de whois alors ... :D

Tu n'as effectivement pas tout compris je pense.

Je n'ai pas interrogé NickServ, j'ai utilisé getaccount qui se débrouille comme il veut avec les CAP du serveur. Sauf que mon pseudo n'est pas enregistré auprès des serveurs IRC mais auprès des services. C'est donc l'ensemble ircd + services qui fournit les CAP.
Si tu lis bien mes logs, tu ne trouveras aucun appel à NickServ ou à un script quelconque, je fais juste une demo avec un eggdrop 1.9 sur un serveur en unrealircd-5.x et anope-2.x.

La seule chose que je déclarais fausse, ou pas bien certaine, c'est ta manière de savoir si l'ensemble serveur/eggdrop pouvait utiliser ces fonctionnalités.

Essaye isidentified au lieu de getaccount

Il reste qu'il s'agit de savoir si l'utilisateur est identifier, ce qui veux dire avoir mode user +R ou +g dans Charybdis. le IRCD donne cette informations avec les capabilities dans les nouvelles version IRCD et eggdrop permet de manipuler cette informations.

https://ircstats.org/server-features/cap/account-notify
https://ircstats.org/server-features/cap...unrealircd

c'est que je n'ai pas compris ton commentaire:
(21/01/2021, 17:43)CrazyCat a écrit : Je peux bien avoir l'info renvoyée par NickServ...


en gros dans ton eggdrop.conf
Code :
https://github.com/eggheads/eggdrop/blob/develop/eggdrop.conf#L1122
tu doit avoir :
Code :
set cap-request "account-notify extended-join"

ensuite essayer isidentified
pour savoir les caps que le serveur support il existe :
tcl
.tcl cap ls
if { ![cap req account-notify]} { die "account-notify indisponible" }



pour revenir au poste initale et repondre a mecmec :

mecmec te prend pas la tête
1) met a jour ton eggdrop a la v1.9
2) ajoute a ta config
tcl
set cap-request "account-notify extended-join"


3) essaye ce code:

tcl
# verification de la presence de account-notify pour l'utilisation de [isidentified ...]
if { ![cap req account-notify]} { die "account-notify indisponible" }
bind pub -|- $tapavu(command)tapavu tapavu:pub:req
 
proc tapavu:pub:req {nick uhost hand channel arg} {
  if { ![isidentified $nick] } {
 
     puthelp "NOTICE $nick :04$nick12, je n'accepte les demandes des utilisateurs non-enregistrés."
     return 1
  }
if {$arg == ""} {
  puthelp "PRIVMSG $channel :12Qui ça 04$nick12 ?"
  return 1
}
tapavu:pubreq $nick $uhost $hand $channel $arg 0
}



Voila une fonction qui retourne true si le pseudo est identifié ..
  Répondre


Sujets apparemment similaires...
Sujet Auteur Réponses Affichages Dernier message
  Fonction banlist MewT 2 2,843 23/11/2010, 17:56
Dernier message: MewT

Atteindre :


Utilisateur(s) parcourant ce sujet :  mcdeffice, 1 visiteur(s)