-
« Comment valider une adresse email avec une REGEX »
NON SURTOUT PAS ! Il est mathématiquement impossible d'écrire une regex pour valider un e-mail.
Utilisez plutôt
filter_var()qui est bien plus rapide et occasionnera beaucoup moins d'erreurs-
Ah bon ? :sceptique:
Merci d'avoir citer filter_var, je connaissais pas. Si un filtre est déjà proposé par le langage, autant l'utiliser plutôt que de réinventer la roue.
-
C'est incomplètement faisable. Et la regex qui peut le plus est une monstruosité https://stackoverflow.com/questions/201323/how-to-validate-an-email-address-using-a-regular-expression#answer-201378
-
-
-
-
Mettez
#!/bin/bash -euet sauvez un chaton d'une mort effroyable !-
Une petite explication du pourquoi ?
-
-edélenche l'arrêt du script en cas d'erreur non gérée. Cela évite l'effet boule de neige où une erreur d'un script déclenche une avalanche d'erreur dans les commandes suivantes du script. Avec-e, bash s'arrête et affiche l'erreur à l'origine de toute la catastrophe qui aurait put se passer ensuite.-uchange le comportement de bash en regard des variables indéfinie. Par défaut, une variable indéfinie est substituée par la chaîne vide. Avec-u, bash lève une erreur et arrête le script. Cela évite notamment les erreurs avec le typo dans un nom de variable.-euest en quelque sorte le mode strict de bash, pour reprendre une terminologie de PHP. Autant, en interactif,-eusont inutilisables, autant dans un scripts ils me semblent indispensables.-
Merci pour l'explication complète :)
-
Notons cependant qu'ils peuvent être inutilisables en script. Dès qu'on commence à faire des trucs un peu complexes, ça peut vite péter. J'ai quelques scripts qui supportent pas
-e(ça pète pour rien).Pour une suite de commandes à la makefile, ça se tiens, mais sinon c'pas toujours possible. Activer/désactiver les options au besoin à coup de set est intéressant et éviter de couper l'exécution durant un traitement correct.
-
-
Heu… non, certainement pas. Ça sert à « inverser » le code de retour, l'effet d'ignorer les erreurs qui suivent n'est qu'un effet de bord. Et ça rends inexploitable le code de retour de la commande (sauf à vouloir explicitement inverser le résultat).
Autant adapter ses scripts à son usage, je veux bien, autant utiliser des bricolages du langage, bof. Sans parler de la lisibilité qui en prends un coup…
Personnellement, je préfère traiter les erreurs (pré-vérifications, récupérations des codes d'erreurs et/ou de la sortie pour déterminer les actions à faire, etc) plutôt que d'activer un réglage Bash qui pourrait me mettre des bâtons dans les roues (en ne catchant pas certains cas que je considère comme erreur malgré le code 0, ou en catchant des cas que je ne trouve pas anormaux malgré le code de retour > 0).
Il m'arrive d'utiliser
-e, mais généralement je l'active que quand j'ai tout un bloc de commandes lancées sans conditions à la suite et qui ne sont pas censées foirer. Du coup si ça plante à cet endroit, c'est qu'il y a un cas totalement imprévu.Au final, ça dépends de la situation, des préférences et habitudes, etc.
-
Ça sert à « inverser » le code de retour
As-tu essayé le bout de script que j'ai partagé ?
! truen'arrête pas le script. C'est à dire que-eignore le retour de!, quelque soit le résultat de la commande. En début de commande,!est en bash comme le-de GNU Make. C'est un autre usage de!.Toute erreur non gérée doit être une rédhibitoire.
-
Ah mais j'ai pas dis le contraire. Je dis juste que
! trueretourne 1. Même s'il arrête pas le script, ça fausse le code de sortie.!sert avant tout à inverser le code de retour, pas à l'ignorer. Ça c'est qu'un effet de bord.Quant à
-u, ça permet d'éviter pas mal d'arrachages de cheveux. Perso je teste systématiquement à coup detest -zoutest -nles variables qui doivent absolument ne pas être vides (et j'ai aussi des cas de variables légitimement vides).Après, mettre
-eupar défaut et ne le virer que quand on a besoin (avecsetpar exemple), c'est plutôt une bonne idée, surtout si on a pas l'habitude de certains comportements de Bash (qui varient de ce qu'on trouve ailleurs).Bref, question d'habitude, chacun fait ce qu'il veut, tant que c'est en connaissance de cause.
-
Exactement, il m'arrive d'encadrer du code pas fiable avec
set +eu; ...; set -eudans le pire des cas. C'est très rare dans mon expérience.Je trouve que les
if $? ...sont très verbeux. Pire, j'ai vu un collègue écrire des script avec&&à la fin de chaque ligne.-erends les scripts plus lisible à mon goût.
-
-
-
-
-
-
-
-
-
Ils ne savaient pas que c'était impossible, alors ils l'ont fait.
Réussir à analyser le sens du papier toilette et faire le lien sérieusement avec le métier de consultant, c'est magnifique.
Je suis à la fois subjugué et consterné.
-
Je trouve l'idée très bonne mais absolument pas celle de supprimer automatiquement les messages de plus de 6 mois.
Internet n'oublie rien et ce n'est pas en forçant cette suppression que cela va changer quelque chose. Il aurait été plus intéressant, je pense, de proposer un menu interactif avec la liste des messages postés et une case à cocher pour tout sélectionner puis effacer proprement.
-
Je ne sais pas trop quoi pensé de cette fonctionnalité.
D'un côté je trouve dommage de perdre des sujets et messages qui pourrait être utile bien plus de 6 mois. J'ai l'impression que c'est la construction d'une communauté qui est effacé.
D'un autre, pas mal de personne veulent pouvoir supprimer leurs anciens messages avec lesquels ils ne sont plus en accord.
Ta solution me séduit plus que l'actuelle. C'est un bon compromis je trouve.
-
-
-
Mirabellette plus de 4 ans | lien | sur : Développeurs, vous devriez avoir honte — Règles de mots de passe
La taille n'est pas le seul facteur en prendre en compre pour mesurer la solidité d'un mot de passe. Par exemple, en ligne, le nombre de tentative possible par minute est beaucoup plus faible qu'en offline car il existe des mécanismes pour éviter les attaques par force brute.
Pour information, la CNIL a publié un guide sur les règles concernant la longueur des mots de passe et l'on voit bien que des mots de passe de 8 caractères sont jugés acceptables par la CNIL pour les sites internet si d'autres critères sont présents. https://www.cnil.fr/fr/authentification-par-mot-de-passe-les-mesures-de-securite-elementaires
Faire les calculs, c'est bien, savoir de quoi on parle, c'est mieux. Encore plus quand on veut faire la leçon aux développeurs.
-
Les calculs qu'il donne sont sur la génération des hash de mots de passe. Donc quand on connaît le sujet et qu'on sait de quoi on parle, on comprend très vite que c'est plutôt en lien avec le cas d'un leak de BDD contenant des empreintes de mots de passe.
Donc avant d'accuser les gens de ne pas savoir de quoi ils parlent, tourne sept fois la langue dans ta bouche, et ensuite prend ton clavier… ou pas.
-
Même si on parlait d'un cas d'un leak de base de données, son argumentaire ne tient pas. L'exemple de calcul qu'il fait se base sur des hash réalisé avec l'algorithme SHA256 ?
Qui utilise l'algorithme SHA256 pour stocker des mots de passe et est développeur en 2019 ?
On utilisera plutôt argon2 ou bcrypt pour réaliser cette tâche. Ces algorithmes sont beaucoup plus long à calculer que les algorithmes de type SHA* De plus, les bonnes pratiques du côté des sauvegardes en base de données et d'ajouter un sel et de jouer n fois l'algorithme de hash dans le but de ralentir encore plus les attaques par forcebrute à froid.
L'idée n'est pas mauvaise en soi, plus la taille des mots de passe est long et sans contraintes de caractère, mieux c'est. Par contre, je trouve que les arguments pour encourager cette démarche ne sont pas vrais.
Une fois que la bdd a fuité, c'est gameover. Il faut faire changer les mots de passe de tous les utilisateurs, peu importe la longueur.
-
-
-
Je trouve ça courageux de publié cet article, +1
Utilisation d'une méthode d'authentification qui présente deux vulnérabilités potentielles (to access token leakage and access token replay). L'url contenant le jeton étant récupérée par les outils de métriques, la fuite de données (authentification et ici personnelle) est avérée.
Belle découverte :)
-
Super ! Plus qu'à attendre quelques mois avant de pouvoir l'installer en production. Hâte de pouvoir mettre du TLS 1.3 :)
-
Bonjour,
Je vote peu voir pas du tout sur le site.
Les articles pour lesquels je vote positivement sont en général des articles complets avec beaucoup d'informations ou avec des informations rares. Se faisant, il m'arrive de les étudier en détail que quelques semaines voir mois plus tard.
Je ne prends alors pas la peine de voter pour eux sur le site du journalduhacker car je me dis que cela n'a plus vraiment de sens (à tord je ne sais pas) et que je ne prends pas le temps de les retrouver.
-
Attention à l'imprécision !!
Je cite dés le deuxième article : “Le trio d'une configuration d'Asterisk pragmatique + fail2ban + iptables va nous permettre de nous mettre en sécurité contre la quasi-totalité des attaques que peut subir notre serveur Asterisk.”. x. Certes, le traffic généré par les bots représentent 99% du traffic malveillant. Cependant, si vous êtes une cible intérssante, fail2ban montrera rapidement ses limites face au 1% restant.
Fail2ban peut s'intégrer dans une politique de sécurité mais il ne peut pas en être l'unique acteur.
-
Bonjour,
Mis à part qu'il est clairement recommandé de ne plus utiliser Iptable car considéré obsolète.. et qu'il (f|v)aut se mettre à son remplaçant nftables ! (un coup de manpage sous Debian, c'est explicite)
un article obsolète, en retard de plusieurs années !
Désolé.
-
-
Merci pour le commentaire, je savais pas que iptables était jugeait obsolète. Après avoir lu le wiki debian, c'est principalement la complexité du “framework” iptables qui l'a amené à être mis au rebus.
Je suis également d'accord avec Cascador, ton commentaire est très dur. L'article de kikinovak est très bien et complet. Le fait qu'il présente le fonctionnement d'une technologie amené à être considéré obsolète en 2024, soit dans 5 ans n'en fait pas du tout un article obsolète en retard de plusieurs années !
edit : après avoir pris quelques minutes pour faire des recherches, j'ai pas l'impression que nftables soit unanimement validé. Je vais rester sur iptables en attendant que cela se décante.
-
-
-
-
-
Je suis très surpris de voir les réactions si négatives et les intentions qui me sont données. Si on ne peut donner son avis, sans être si durement jugé, c'est une farce et une pantomine.
Rien dans ma remarque n'est désobligeant, et encore moins trollesque. Il faudrait revoir les définitions des termes. Que le commentaire soit considéré comme dur, voire très dur, je peux le comprendre. Mais ça ne mérite en rien le déchaînement de passion négative et l'assaut en règle de celui-ci !
Je suis mesuré dans mes propos… et je tiens à le reste. Je ne me permet aucune attaque ad hominem. Et il est normal qu'on le reste aussi. @kikinovak n'a pas l'air d'apprécié qu'on ne soit pas d'accord avec lui. Son effort de vulgarisation est louable, mais ces petites imprécisions m'agacent. Et, j'ai le droit de le ressentir… mais apparemment pas de l'exprimer, puisque cela déchaîne des vélléités destructrices à mon encontre.
Je n'y peut rien, personnellement, si systemd jette aux oubliettes iptables, et met aux alouettes nftables. Je n'y peut rien, si systemd tend à imposer certaines choses.
De toute façon, j'ai de plus en plus tendance à fuir Debian, et de fait, Linux, à cause des pratiques ‘systemd’ - surtout quand je vois la facilité d'administration d'OpenBSD, auquel je suis coutumié depuis quelques années… et quand je vois la simplicité de PF - Packet Filter - face ne serait qu'à côté d'Iptables - et, je ne parle même pas de nftables et autres consorts - je suis très sceptique sur le reste. Mon seul regret est que Debian GNU/kFreeBSD ne décolle pas. Au moins, on garderait l'avantage des deux mondes, et le meilleur de ces deux mondes.
(il est vrai, malheureusement, que pour OpenBSD, il est strictement nécessaire d'avoir du matériel compatible ; pour ce qui est des autres Linux, autres que Debian, voire Ubuntu, je n'en sais strictement rien, ils ne m'ont jamais attiré, même si j'ai eu pratique SuSE en environnement entreprise, mais jamais aimé.)
Mais je retiens la leçon : ne rien exprimer de contre à-propos de ce monsieur et de ces articles. Donc, dorénavant, quand je verrais un article de @kikinovak, je passerais carrément mon chemin, aussi pertinent soit son analyse, ou pas.
Bonne fin de week-end !
-
Une suggestion pour l'avenir : comprendre la différence entre la critique descriptive et la critique prescriptive.
Exemple de critique descriptive : “L'auteur écrit un article sur Iptables, une technologie encore actuelle dans les distributions Linux de qualité entreprise, mais tendant à être remplacée par $NOUVELLE_TECHNOLOGIE dans les années à venir. D'ailleurs, une erreur factuelle s'est glissée dans le Xème paragraphe, lorsque […]”
Exemple de critique prescriptive : “Ça devrait être interdit de publier des articles pareils.”
Toute critique constructive de mes articles est évidemment bienvenue. En règle générale, quand il m'arrive d'écrire une ânerie, mes lecteurs me le font très vite savoir en ajoutant un commentaire en bas de l'article correspondant. Je suis toujours reconnaissant pour ça, parce que ça crée un contrôle de qualité qui me semble caractéristique du monde de l'Open Source.
Der Ton macht die Musik. (proverbe de mon pays natal)
-
Et c'est toi qui me répond cela avec les jugements de valeur, à l'emportée, tels que tu les as faits.
Merci du conseil. Bye !
-
-
-
-
-
-
-
Eh oui certaines technologies dans des environnement très évolutifs comme les container montrent leurs limites. Voici un chouette article en anglais sur BPF : https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/ et qui montrent pourquoi BPF est apprécié.
Sinon, travaillant dans un environnement professionnel très varié, je constate que le choix des briques est souvent complexe.
Le choix de Redhat, avec sa politique de support encourage parfois à un attentisme. Il est vrai qu'entre stabilité et innovation l'équilibre est parfois difficile !
-
Plus généralement, je conseille la lecture de l'excellent ouvrage “Trop Vite” de Jean-Louis Servan-Schreiber, qui traite de l'effet néfaste de l'accélération de notre quotidien dans tous les domaines (technique, financier, politique, amoureux, etc.) et de toutes ces cibles mouvantes qui nous pourrissent la vie. Ne pas confondre avec le bouquin de Nabilla qui porte le même titre, hein.
-
-
-
-
Si j'ai bien saisi les posts de ce Camille Roux sur le JdH, c'est de la pub pour sa boîte qui vend des cookies à prix d'or, ainsi qu'une série d'articles sur le comportement politiquement correct et l'écriture inclusive.
-
-
Et vu la popularité de ce genre d'articles, soit les lecteurs du JdH adorent les cookies surfacturés, soit le gars dispose de son propre cortège de plussoyeurs professionnels. Du coup ce serait pratique si on pouvait plonker un auteur, comme au bon vieux temps de Usenet.
-
Ou alors parce qu'on aime les retours d'expériences.
-
-
Là l'article aborde un point intéressant : les personnes qui tentent de décourager les entrepreneurs abordant un marché qui apparaît de but en blanc saturé et le fait qu'en l'abordant différemment ou plus efficacement on peut évoluer dans ce créneau.
Pour le fait qu'il parle de sa boîte, 99% des articles d'entrepreneur parle de leur projet/entreprise. Dur de détailler un retour d'expérience sans exemple concret.
-
-
-
-
-
-
Merci pour tout et longue vie au Journal du hacker :)
-
Selon moi, ce n'est pas de la responsabilité du navigateur de gérer comment les requêtes DNS sont transférées et quel résolveur est utilisé. D'autant plus qu'il propose l'option en OPT-IN, juste abusé. L'option VPN de Opéra est une option OPT-out.
Qu'ils essayent de faire un navigateur performant, ergonomique et sécurisé et cela sera très bien.
-
- Un tutorial pour installer le système d'exploitation LineageOS sur un smartphone
- L'article du mois concernant l'activité du blog et le soutien à la communauté
-
- Quelques mise-à-jour de mon serveur et optimisation.
- La rédaction d'un premier article sur les principes importants à connaître en matière de cybersécurité.
-
C'est ce qu'on appelle typiquement une non offre. On cherche un lead tech avec 5 ans d'expérience dans le développement mais on te précise pas quel langage.
Un lead dev en php n'en fait pas un lead dev en java.
Ce genre d'articles publicitaires ne sont pas interdits ici ? J'espère que oui.
-
-
Oui mais non. Certaines offres d'emplois n'en sont pas vraiment et font office de publicités pour les entreprises. L'objectif étant de montrer qu'elles sont en croissance et active sur le terrain du recrutement.
Au vu du manque d'information fondamentale, on peut légitimement se poser la question si cette offre est réelle ou non.
Je n'avais pas du tout perçu cette dimension au site du hacker, n'ayant même pas vu le tag emplois, my bad. Concernant sa présence ici, j'espère ne pas voir le journalduhacker se transformer en site de recherches d'emplois marketinginsé.
-
-
-
Absence totale de réponse sur les réseaux sociaux. Vu que c'est une SSII, et que j'ai déjà vu cette “stratégie” (on poste une annonce de recrutement alors qu'il n'y a aucun poste derrière pour faire croire que tout va très bien madame la marquise), ça pue l'embrouille com' au dépend d'une réelle offre d'emploi.
-
EDIT : via twitter : « Hello ! C'est un poste en CDI, basé à Paris 8ème. La rémunération est selon profil. Intéressé ? » ils ont complété l'annonce ce matin. Par contre, toujours aucune explication sur le langage, les technos, les méthodologies, les méthodes d'organisations.
-
Il s'agit bien d'une vraie annonce, nous avons trois postes à pourvoir pour le moment. Nous sommes présents sur Paris et Toulouse, et nous sommes assez ouverts en termes de technos, on cherche surtout quelqu'un qui souhaite monter en compétence sur le Cloud, idéalement AWS. Encore désolés si l'annonce n'était pas assez claire, et n'hésite pas si tu as d'autres questions.
-
-
-
-
Que de violence :o
Autant je ne suis pas d'accord avec la conclusion mais est-ce que cela justifie une telle aggressivité ? Après je comprends parfaitement qu'il est difficile de ne pas réagir violement quand on se sent insulté et incompris.
Cependant, expliquer calmement les choses reste selon moi la meilleure façon de faire progresser tout le monde.
Accepter que les gens pensent différement fait partie du jeu. Ils peuvent avoir raison, ils peuvent se tromper, ainsi soit-il.
-
-
C'est est une question de sensibilité, je comprends la réaction de certains même si je ne la cautionne pas.
Cependant, là où tu as pleinement ta part de responsabilité est dans ta gestion de la controverse et de la souffrance que tu provoques. Je ne sais pas si tu t'en rends compte à quels point dans tes réponses les mots que tu emploies et les accusations que tu portes sont extrêmement violentes.
Un exemple provenant des commentaires ici et ceux pris sur l'article en question:
“La nature de la relation la Quadrature du Net aux GAFAM est de même nature que celle du militant antinucléaire au nucléaire. Elle est existentielle ! A chacun son business plan.”
Tu réduis le choix d'utiliser les GAFAM à un business plan. C'est cynique et de mauvaise foi quand on sait qu'il n'y a pas d'alternatives à eux pour toucher le grand publique. Le militant anti nucléaire peut utiliser une énergie verte, par contre, est-ce qu'il va influencer les autres, pas vraiment.
“Tu fais partie du comité de censure ?” Dire cela de quelqu'un équivaut à dire qu'il menace l'une de tes libertés fondamentales à savoir la liberté d'expression. Je suis d'accord que le message initial n'invite pas à la retenue mais c'est de ta responsabilité d'élever le niveau.
“Pauvre garçon !”
“C’est ça. Maintenant, il faut aller se coucher les enfants ! ;+)”
“Tes injonctions, je n’en ai rien à faire. Pour tout te dire, je n’ai pas pris le temps de lire tous ces galimatias. J’ai autre chose à faire. ” Quel mépris incroyable quand tu vois la longueur du message qu'à fait Elzen pour te répondre et le temps qu'il a du prendre pour l'écrire.
Je vais m'arrêter là.
N'attends pas qu'autrui fasse preuvent de retenu, de mesure, de considération et de bienveillance à ton égard si tu n'en a pas pour lui.
-
-
-
Je finalise mon outil de statistique relative à la fréquentation de mon blog basé sur les logs du serveur web. J'ai quelques graphiques des données qu'il me semble importante pour moi.
- nombre de pages vue par mois / jour
- classement des pages les plus vues par mois / jour
- liste des sites sources pour le mois / jour
Avec une très grosse attention sur le caractère personnelle des données. Faut que je regarde si la donnée du referer n'en est pas une. Pas si simple car certains referer peuvent être des sites personnels du genre madamemichu.fr ; Bien que super utile pour connaître un peu son audience et décrouvrir des mines d'or en site, il y a de fortes chance qu'elle passe à la trappe.
-
Merci d'avoir fait figurer l'article sur l'hébergement des marques pages Firefox dans la liste des liens intéressants du journal du hacker de la semaine 21. :)
-
Super article, j'en ai appris pas mal, merci :)
De rien :-)