OFFENSIVE FIREWALL
uaip
Messages postés
1466
Date d'inscription
mardi 20 février 2007
Statut
Membre
Dernière intervention
7 février 2011
-
12 oct. 2008 à 03:54
monsieur_canard Messages postés 22 Date d'inscription vendredi 11 août 2006 Statut Membre Dernière intervention 30 octobre 2008 - 30 oct. 2008 à 22:24
monsieur_canard Messages postés 22 Date d'inscription vendredi 11 août 2006 Statut Membre Dernière intervention 30 octobre 2008 - 30 oct. 2008 à 22:24
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/48113-offensive-firewall
https://codes-sources.commentcamarche.net/source/48113-offensive-firewall
30 oct. 2008 à 22:24
Ce code ne sera plus mis à jour.
Je serais donc heureux que les admins le supprime.
Merci.
29 oct. 2008 à 00:06
29 oct. 2008 à 00:05
Alors oui, effectivement, c'est une erreur de connexion.
En fait, puisqu'il n'y avait pas beaucoup de mouvement, j'ai éteint le serveur.
Mais je le remettrai en route dès que possible.
D'ailleurs, je ne peux me permettre de garder ce serveur allumé tout le temps, car je squatte la connexion d'un voisin.
Donc, si quelqu'un pouvait faire en sorte de mettre un serveur en place, ce serait bien (quoique la partie serveur n'est toujours pas terminée...).
Je mettrai les codes à jour dès que possible.
@+
28 oct. 2008 à 22:59
"if ($sockerr) { report err $qt($sock($sockname).addr) : sockerr } "
Et dans ton cas, c'est sur en ouvrant un socket sur "stqned.ath.cx" ($qt($sock($sockname).addr)).
Donc en gros, il y a eu une erreur, quoi.
28 oct. 2008 à 20:35
[19:38:01] [INFO] Loading user's configuration...
[19:38:02] [OK] (firewall) Tous les ports sont à l'écoute.
[19:38:23] [ERR] "stqned.ath.cx" : sockerr
que signifie la 3em ligne?
merci
17 oct. 2008 à 20:16
Le C est venu après, alors qu'il projetait de refaire ce code dans un autre langage, sans trop savoir lequel.
Et puis non, ce n'est pas simplement pour la lisibilité que le $iif() est déconseillé, c'est aussi en rapport avec le temps d'exécution (bien que la lisibilité y soit aussi pour quelque chose, je ne le nie pas).
Il suffisait simplement que tu rajoutes un petit commentaire du style "Le $iif() est également déconseillé pour sa lisibilité." cela aurait évité cette discussion plutôt sans queue ni tête (bien qu'elle ne soit pas totalement inutile).
Bref, j'ai mal choisi mon mot "convention", je l'avoue. Pour le reste je n'ai pas tord, bien que je n'ai peut-être pas exprimé l'idée de la lisibilité, ce que tu as corrigé.
Disons... "Fin de l'histoire".
17 oct. 2008 à 19:22
Ce quie est bizarre, c'est que tu lui dis de ne pas utiliser $iif en tant que commamd, l'OP (original poster, celui qui a fait la source ici)) te demande pourquoi, et derriere t'es partis ds ton delire sans meme lui dire pourquoi.Tu ne lui a pas dis une seul fois que on (les scripteurs) recommandais d'eviter cela parce que ce n'est pas propre, ce n'est pas une facon d'executer une cmd, que quand qqun voudra lire ton code, ca le pertubera etc... et la une fois que j'ai moi donne mon avis sur pourquoi on recommandais cela, toi tu dis, "c'est exactement ce que j'ai dis" bah moi je trouve pas.Mais bon, au final on est d'accord, dsl d'etre si casse couille :] et dsl pour les accents, ca rend vraiment dur a lire
17 oct. 2008 à 16:14
"Jsuis pas d'accord, si tu code pour toi, tu fait ce que tu veux"
-> or quand on poste une source sur un site, on ne code plus pour soi.
"apres c'est sur que je recommande a personne de le faire, mais c'est simplement un conseil general, par ex si le mec post un code ici, je lui conseillerai de faire en sorte que son code soit plus clair, mais libre a lui de laisser son code comme il veut"
-> c'est exactement ce que j'ai dit, donc nous sommes d'accord.
Quant à la 'convention', j'ai peut-être mal choisi mon mot. Disons qu'il y a plutôt certaines 'normes' (ou normalisations) concernant la syntaxe de programmation.
Par exemple, éviter d'utiliser le 'break' ou 'return' dans une boucle 'for', agencer son code afin d'éliminer les éventuels goto, etc...
Rien "d'officiel" donc, et je dis ça à contre-coeur car je suis un des premiers à utiliser 'return' dans mes 'for'...
16 oct. 2008 à 22:43
Cependant, ce n'est pas parce-que mIRC le permet qu'il faut le faire. Il y a des conventions.
Jsuis pas d'accord, si tu code pour toi, tu fait ce que tu veux, tu empechera pas un mec de coder a sa maniere, si qqun a envie d'utiliser que des $iif en debut de ligne, il peut, apres c'est sur que je recommande a personne de le faire, mais c'est simplement un conseil general, par ex si le mec post un code ici, je lui conseillerai de faire en sorte que son code soit plus clair, mais libre a lui de laisser son code comme il veut, et pour finir je sais pas d'ou tu sors qu'il il y a une convention, ya rien du tout :/ (j'ai p-e mal compris ce dernier point)
16 oct. 2008 à 20:38
Je n'ai jamais dit que le $iif() était interdit, mais j'ai conseillé de ne pas l'utiliser, histoire de rester rigoureux avec la norme. Quant à l'exemple du parser, je n'ai pas non plus insisté sur un éventuel lien entre ces deux "idées", c'était simplement un exemple pour illustrer la [mauvaise] idée du "puisque mIRC le permet, alors je le fais".
Enfin, il faut sortir du contexte de mIRC.
En C aussi, tu peux faire:
int variable=1;
(variable)?printf("ok"):printf("pas ok");
Ca fonctionne aussi, mais c'est d'abord pas clair (comme tu dis) mais surtout très déconseillé au niveau de l'exécution.
Puis, je ne sais pas si tu les as lu, mais les liens que j'ai donné, ce n'est pas moi qui les ai écrit ^^
16 oct. 2008 à 19:44
15 oct. 2008 à 10:49
Cependant, note quand même que la plupart des langages sont multi-plateformes (sauf si tu utilises des apis spécifiques) et tous peuvent se "contrôler" par terminal.
Enfin bon, le python est une bonne idée je pense.
Bonne chance ^^
15 oct. 2008 à 05:01
J'ai un peu continué le client...
Les bases sont créés, il ne reste plus qu'à tout arranger pour que cela fonctionne tout bien comme on veut (bien que là il doit déjà faire le minimum sans problème).
Pour ce qui est du portage, je crois que je vais m'orienter vers python...
Ce langage me semble complet, rapide, pas trop complexe ET multi-plateforme =)
Pour ce que j'ai vu (j'ai regardé rapido 5 ou 6 sources), ça doit être faisable.
Surtout que, finalement, je n'ai pas réellement besoin d'interface graphique, donc le terminal\cmd me suffit amplement!
@+
14 oct. 2008 à 23:44
- en Perl, mais uniquement pour un bot IRC (et ça date tellement que je serais incapable d'écrire une ligne de Perl aujourd'hui)
- en TCL, également pour un bot IRC (entre autres) mais les sockets étaient lancés à partir d'un shell distant UNIX
- en C/C++, ça n'est pas 'horriblement' très dur, mais faut quand même vachement bien maitriser (et chez moi, les sockets c'est pas mon fort)
Je ne sais pas si tu maitrises d'autres langages que le mIRC scripting, mais si la réponse est non, alors attends-toi à pas mal de complications.
Je prends l'exemple du C parce-que c'est celui que je maitrise le mieux aujourd'hui, et sache que ce que tu fais en 1 ligne en mIRC scripting (un 'sockread %a' par exemple), il te faudra une dizaine de lignes pour le faire en C. (déclarer tes variables de réception, le buffer de transition, ouvrir des thread si tu ne veux pas freezer ton programme, etc).
Si tu veux voir l'allure du code (la syntaxe), tu peux jeter un oeil ici, sans forcément lire les explications (sauf si ça t'intéresse vraiment):
http://c.developpez.com/WalrusSock/
Mais en même temps je ne me suis intéressé qu'aux 'gros' langages bourrins. Donc je ne pense pas pouvoir t'aider vraiment sur le choix d'un langage. Pour un firewall, tu dois sans doute avoir des langages assez sympas, fluides et pas très compliqués, genre VB, java, ou autres...
Explication ici en VB: http://www.vbfrance.com/codes/CREATION-FIREWALL_5730.aspx#comments
Et au pire google > 'créer firewall', ou sur ce même site > 'firewall', etc...
Désolé d'écrire des gros pavés à chaque fois, je me doute que ça doit être un peu chiant à lire.
Bref, bonne chance :)
14 oct. 2008 à 19:14
Ceci dit, je ne sais pas si je vais continuer à 'développer' cette source (sous mIRC du moins), car les 'ajouts de fonctions' que je veux faire demandent pas mal de travail...
Et finalement, je me dis: "tout ce travail pour un simple addon mIRC, c'est quand même une belle perte de temps", je vais donc de ce pas essayer de trouver un autre langage assez simple vers lequel porter tout ça.
Tu n'aurais pas une petite idée? :-S
(PS: Merci pour l'attention que tu apportes à cette source :P).
14 oct. 2008 à 19:07
On se dit "bof, ça marche, alors même si c'est pas bien je le fais quand même".
Mais plus ça va, et plus on a envie d'être rigoureux.
Enfin bon, vu ton code, t'as plutôt l'air de bien gérer (en mIRC scripting du moins) donc je n'ai pas tellement de leçon à te donner la dessus. C'était un simple conseil.
14 oct. 2008 à 18:42
Je comprend maintenant ce que tu veux dire...
Seulement, je n'ai jamais rencontré de soucis à procéder ainsi. Et jusqu'à présent, cela m'a permis de gagner une ou deux lignes (généralement une...) assez régulièrement.
De plus, le fait d'utiliser les $iif() pousse généralement à l'optimisation du code. :P
MAIIIS, je tiendrais compte de cette remarque pour la prochaine MAJ =)
@+
14 oct. 2008 à 18:18
En fait, le $iif() est un identifieur, il ne fait donc que retourner une valeur.
Le mIRC permet d'interpréter les commandes comme des valeurs.
Par exemple: $iif(%a == %b,echo -a oui,echo -a non) affiche 'oui' ou 'non' en fonction des variables.
Cependant, ce n'est pas parce-que mIRC le permet qu'il faut le faire. Il y a des conventions.
Une syntaxe valide (pour le même exemple): echo -a $iif(%a == %b,oui,non)
Ici l'intépreteur va d'abord évaluer la condition, et en fonction des variables, il va retourner 'oui' ou 'non' à la commande 'echo' qui va ensuite afficher cette valeur.
Si tu n'es toujours pas convaincu par mon blabla, je te donne un exemple très simple:
en tapant '//echo -a ligne 1 } echo -a ligne 2' l'interpréteur voit ici 2 commandes, confondant le '}' avec le |' (dans ce cas).
Il va donc afficher deux lignes, mais c'est une erreur de la part de mIRC. Il ne faut donc pas le faire non plus.
Si ça t'intéresse, tu peux jeter un oeil ici:
http://en.wikipedia.org/wiki/IIf
ou ici:
http://en.wikipedia.org/wiki/Conditional_statement
Ils expliquent très bien pourquoi le $iif() a été créé (simplement pour permettre l'utilisation des if à l'intérieur d'expressions). Mais en aucun cas il ne doit remplacer le if.
Voili voilou. (Si vraiment je ne t'ai toujours pas convaincu, je te conseille vivement de lire le 2ème lien).
Bonne continuation :)
14 oct. 2008 à 15:54
Mais ... pourquoi devrais-je éviter d'éviter les $iif() ? Peux-tu argumenter stp? :p
Et par ailleurs, je n'arrive pas à situer ceux dont tu parles (en début de lignes), pourrais-tu être un brin plus explicite?
= /!\ ===
La source à été partiellement réécrite (j'ai eu du mal à m'y replonger après 1semaine sans y toucher :-S), donc ton commentaire n'est peut-être plus valide.
Cependant, je n'ai pas changé ma "manière de coder", et j'utilise toujours autant les $iif() :p
12 oct. 2008 à 03:54
Néanmoins, je te conseillerais d'éviter les $iif() utilisés comme commandes (en début de ligne, quoi).
Sinon je trouve ça fluide, l'utilisation des sockets est propre, c'est pas mal.
(Je n'ai pas testé).