Ses derniers messages sur les forums
Ne te dévalorise pas, ce n'est pas facile le développement web. Ceci dit, /a priori/, ce système n'est pas bon car il est prédictible.
Pour qu'un captcha soit bon, il faudrait qu'il soit totalement aléatoire.
Mais là il y a trop de code, tu devrais diviser tout ça pour déterminer où sont tes erreurs. Déjà, la fonction NoSpamQuestion me semble suspecte. Regarde là de plus près :)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Tu soumets ton formulaire en HTTP POST, il faut donc récupérer tes données dans le super-global $_POST.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je pense que tu ne trouveras personne qui connaisse MS SQL Server ici. Ceci dit, j'ai déjà lu que jouer avec l'installation de différentes versions de MS SQL Server entraînait une peine certaine :)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Il y a beaucoup de logiciels qui s'appellent comme ça.Il faut que tu nous donne un lien pour qu'on sache de quoi tu parle. As-tu fais un premier jet ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Désolé d'arriver aussi tard. Mais en fait, il y a plus simple pour agréger des stats avec MySQL.
Tu as les clauses avg, sum et group by pour t'aider.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Microsoft fournit un support pour Microsoft SQL Server. Tu devrais regarder de ce côté là.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Si je savais ce qu'est un datagrid Java ou .Net, je ne te demanderais pas de préciser le comportement de ce que tu veux faire.
Sans plus de précisions, ça va être difficile de te conseiller.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Je connais l'argument de l'injection SQL. Mais l'existence d'annuaire de hash MD5 rend la protection caduque. Du coup, pour éviter les injections SQL, le seul moyen est de les éviter en codant correctement les requêtes.
Mais dans l'absolu, c'est un problème de compromis. J'ai travaillé sur un SI où j'avais accès à l'ensemble des mots de passes de l'ensemble des clients de la société qui m'employait. C'est quelque chose qui m'avait choqué, mais à l'usage, il n'était pas possible de faire autrement. Ça aurait été trop coûteux.
Je ne vois pas la différence de difficulté d'usage entre MD5 et SHA qui justifierai qu'on privilégie une méthode dépassée, en laissant croire qu'on a apporté une protection suffisante.
Il faudra dire à la Caisse d'Épargne que 4 chiffres c'est trop faible ;) Mais je suis d'accord dans l'absolu que ce n'est pas suffisant. Mais alors pourquoi proposes-tu de générer un mot de passe faible ?
Ce que je proposerais est plutôt un truc de ce genre :
<?php
define(CANDIDATES, 'abcdefghijk....z12...90$!@') ;
define(SIZE_PWD, 42) ;
$password = substr(str_shuffle(CANDIDATES), 0, SIZE_PWD) ;
Ensuite, si tu veux donner la possibilité à l'utilisateur de choisir son mot de passe 'azerty', c'est un choix bien plus dangereux que d'enregistrer les mots de passe en clair dans la base de données ;)
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
À quoi sert le formulaire ?
À quoi sert le tableau ?
Quel est le but de l'application ?
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
Ton message est incompréhensible. En français correct, ce serait bien.
Développeur récurrent, procédural et relationnel. Caustique soupe-au-lait.
