La version 0.15 est une version majeure, qui apporte une correction de nombreux bugs, la suppression de SQL (pour simplifier l’installation), de nouvelles variables pour les modules : zone_contacts qui est le champs des contacts de l’utilisateur, zone_medias qui est le champs des médias de l’utilisateur (photos, vidéos, son...).
Cette version apporte surtout la décentralisation qui n'était pas encore implantée jusque là. Le protocole utilisé est simplement basé sur HTTP pour être utilisable par PHP, et éviter de passer par des binaires qui ne peuvent pas être installés chez la plupart des hébergeurs.
Tapage n'est pas encore parfait, les défauts sont dans la suite de la dépêche. Tapage n'est toujours pas user-friand. Il reste des bugs, la CSS fait mal aux yeux, l'utilisation de GET pour éviter de se déconnecter entre deux pages n'est pas sexy et le code source n'est pas super propre.
De plus il manque plein de modules. Il y en juste quelques-uns qui font juste le strict minimum : écrire du texte, micro-blogger, changer de page sans perdre la session... Sans compter que la décentralisation n'est pas parfaite, quelques points ralentissent la propagation des données lors de la sauvegarde d'une page.
Le développeur principal de Tapage s'est donné comme objectif de corriger ces défauts pour la version 0.2, qui n'est pas pour tout de suite vu le nombre de nouveautés prévues. Sans compter que le serveur principal du projet va devoir fermer dans moins d'une semaine car personne n'a donné de l'argent au projet depuis la création.
Aller plus loin
- Tapage (24 clics)
- Code source (.tar.gz) (12 clics)
# jugaison
Posté par mr_maurice . Évalué à 2.
Tapage fournit# Petit détail...
Posté par Olivier (site web personnel) . Évalué à 5.
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 9.
Quand je parle de trou de sécurité, c'est par exemple:
'');
Le contenu de $info provenant d'un cookie. D'ailleurs, un cookie c'est fortement limité en taille.
$arr[$_GET['id']]['value'] = stripcslashes($_POST['txt']);
La programmation avec les magic quotes activées, c'est mal.
echo '// \''.time().$_COOKIE['mail'].'\' en sha1 : zone_case.dev_id = \''.sha1(time().$_COOKIE['mail']).'\';';
Argh!
if($_GET['code'] != 0 AND preg_match('#^[a-z0-9._-]+@[a-z0-9._-]{2,}\.[a-z]{2,4}$#', $_GET['mail']))
Confusion entre and et && (qui n'ont pas le même comportement). Utilisation des comparaisons non-stricte (par exemple, 'toto' == 0 est toujours vrai)
La Regex est fausse, une ignominie. En PHP, il faut utiliser filter_var pour ce genre de chose. Cette regex refuse des adresse légitimes syntaxiquement telle que toto+tartare@example.com, sans compter les .museum, etc.
Les commentaires en français, programmer en français, ça n'a pas d'intérêt, surtout quand on écrit un logiciel libre (il n'y a pas longtemps, j'ai eu le bonheur de tomber sur des commentaires en Kanji, haha).
$serveur = file_get_contents('http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur');
Ça fait mal au postérieur ça. Très mal.
if($_GET['captcha'] !== $_SESSION['captcha'] )
Bug de session à l'horizon.
Et beaucoup de copier-coller, le script ajax.php long comme un bras et pas une seule fonction à l'horizon (je n'en suis même pas à me plaindre du défaut d'encapsulation, c'est dire).
Bref, va falloir bosser pour rendre ça utilisable. Parce qu'aucune bonne pratique de base n'est appliquée. Aucune. Bref, c'est un prototype, à ne surtout pas utiliser en production.
Au fait, les CSS, c'est mieux que le style inliné dans le HTML.
Une bibliothèque Javascript (jQuery, prototype ou autre) est aujourd'hui indispensable pour une application d'envergure.
Une bonne pratique pour éviter les bogues dans Javascript, c'est de déclarer correctement les variables (en utilisant le mot-clé var) ou en précisant explicitement qu'on utilises un attribut de l'objet global (window est l'objet global dans un navigateur web).
/* Une fonction qui permet de savoir si le visiteur est sur ça page. */
function if_admin()
{
if(domaine.toLowerCase() == monadresse.toLowerCase())
{
return true;
}
else
{
return false
}
}
C'est quand même plus simple comme ça:
/* Is the visitor admin of this page? */
function is_admin() { return domaine.toLowerCase() == monadresse.toLowerCase() }
À noter que l'emploi de variables globales sans documenté est très mal venu.
Fin bref, du taf :p
[^] # Re: Petitdétail...
Posté par tesiruna . Évalué à 3.
Faire un don.
Merci d'avance, ça devient vraiment vraiment urgent.
J'ai tendance à me demander pourquoi ce sont toujours les mauvais projets qui réclament absolument des dons.
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à 1.
Le cookie contient uniquement l'adresse de la page + le mot de passe. Y'a de la place dans le cookie pour ça.
On passe toujours par la fonction getInfoPage() qui vérifie si le mot de passe est bon.
On utilise jamais le cookie sans passer par getInfoPage().
« $arr[$_GET['id']]['value'] = stripcslashes($_POST['txt']);
La programmation avec les magic quotes activées, c'est mal. »
J'utilise pas les magic quotes ! :/
« echo '// \''.time().$_COOKIE['mail'].'\' en sha1 : zone_case.dev_id = \''.sha1(time().$_COOKIE['mail']).'\';';
Argh! »
...? C'est une méthode comme une autre pour générer un ID unique, pour le développeur.
Mais je préfère utiliser uuidgen.
« $serveur = file_get_contents('http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur');
Ça fait mal au postérieur ça. Très mal. »
C'est prévu de remplacer les file_get_contents par curl.
« if($_GET['captcha'] !== $_SESSION['captcha'] )
Bug de session à l'horizon. »
...?
« La Regex est fausse, une ignominie. »
C'est la regex qu'il y a dans les cours des regex du SDZ.
[^] # Re: Petit détail...
Posté par tesiruna . Évalué à 8.
Je crois que tout a été dit.
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à -1.
Et puis c'est indiqué dans la dépêche que le code source n'est pas propre.
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Si tu n'utilises pas les magic-quotes, pourquoi ce stripcslashes?
Ce n'est pas sha1 que je pointais, mais le CSRF possible avec $_COOKIE['mail'] craché directement dans la sortie standard (qui est à priori le document HTML.
file_get_contents n'est pas le problème. Le problème est d'utiliser une information provenant directement du client Web pour acquérir une ressource, sans faire aucune vérification du contenu, ni aucune protection pour construire l'URL de la ressource.
L'utilisateur va ouvrir plusieurs onglets, ou plusieurs fenêtre sur ton application, dans le même navigateur. Pour peut que le captcha soit requis pour plusieurs actions, le captcha sera certainement régénéré (sinon, il ne sert à rien), et donc les requêtes vont s'invalider les unes les autres.
Le SDZ est malfamé. Il est à proscrire de ces sources d'apprentissage. La raison est que leurs « cours » sont remplis d'imprécisions, d'erreurs et d'a priori de développeurs débutants.
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à 0.
Ça m'étonnerait beaucoup qu'un serialise(adresse/mdp) prenne 4ko.
« Si tu n'utilises pas les magic-quotes, pourquoi ce stripcslashes? »
Les données sont envoyées par ajax, et je me retrouvais avec des \' de partout.
« CSRF possible avec echo $_COOKIE['mail'] »
On ne peut même plus rappeler à l'utilisateur ce qu'il a tapé ?
« http://'.$_GET['adresse'].'/ajax.php?ordre=adresse_serveur
Provenant directement du client Web pour acquérir une ressource, sans faire aucune vérification du contenu, ni aucune protection pour construire l'URL de la ressource. »
Là le seul truc qui ne va pas pour moi c'est que je ne vérifie pas la réponse.
Après, si $_GET['adresse'] contient n'importe quoi, ça retourne false et puis on en parle plus.
« L'utilisateur va ouvrir plusieurs onglets, ou plusieurs fenêtre sur ton application, dans le même navigateur. Pour peut que le captcha soit requis pour plusieurs actions, le captcha sera certainement régénéré (sinon, il ne sert à rien), et donc les requêtes vont s'invalider les unes les autres. »
Au pire ça demande de retaper le capchat et ça marche.
« Le SDZ est malfamé. »
:O
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Donc, tu programme par hasard en virant les quotes sans comprendre comment elles sont arrivées là?
On peut rappeler à l'utilisateur ce qu'il a tapé. Mais toute insertion d'une données qui n'est pas garantie d'être formatée dans le format d'arrivée doit être formatée. Pour le HTML, en PHP, tu utilises htmlspecialchars et/ou htmlentities. C'est au choix. Normalement il faudrait aussi vérifier l'encodage associé.
L'utilisateur peut injecter une URL via $_GET['adresse'], et détourner ton site pour détourner un autre site par exemple, pour que le courroux se déverse sur toi. J'en ai suspendu beaucoup des gugus dans ton genre quand je travaillais dans le support chez un hébergeur Internet.
Au pire, l'utilisateur est ennuyé et ira voir ailleurs si s'est mieux. Je te conseille de lire ce ceci http://sensible.com/ qui parle très bien de l'accessibilité et de ces emmerdeurs que sont les utilisateurs.
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à 0.
Ha, ça, c'est déjà prévu pour tapage 0.2 :
« Par exemple, dans tapage 0.15 il est possible à n'importe quel javascript de se rajouter tout seul comme contact au visiteur. »
[^] # Re: Petit détail...
Posté par Alex . Évalué à 8.
surement, néanmoins au fur et à mesure que ton projet avancera, tu (ou d'autres) rajouteras peut être des infos dans ce cookie. Autant faire ça proprement dès le début. C'est une bonne pratique à avoir
Après, si $_GET['adresse'] contient n'importe quoi, ça retourne false et puis on en parle plus.
Ben justement, la variable ne contient peut être pas n'importe quoi, mais une url valide, mais qui renvoi des données non légitimes, du coup tu ne peux pas faire confiance à ta variable $server.
« CSRF possible avec echo $_COOKIE['mail'] »
On ne peut même plus rappeler à l'utilisateur ce qu'il a tapé ?
J'ai pas lu le code source, et je ne vois pas trop comment exploiter le CSRF ici, sauf utilisateur qui veut se faire du mal à lui même.
Ceci dit il faut imaginer ce que peut faire l'utilisateur si il change lui même la valeur du cookie, soit par un autre adresse mail, soit par du code html/javascript.
Et de manière générale mieu vaut valider toutes les données, ça évite des cas que tu ne soupçonnais pas.
[^] # Re: Petit détail...
Posté par DLFP est mort . Évalué à 4.
Pourquoi ce genre de truc a droit à une dépêche ?
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Petit détail...
Posté par Alex . Évalué à 7.
parce que ça peut permettre de recruter des devs qui rendront le code lisible
parce que si tout les trucs avec des codes crades n'avaient plus le droit de cité, on aurait 2 fois moin de dépêche.
pour pour le coté en "en français", c'est parce qu'en France on est les meilleurs, on a donc pas besoin des incompétents des autres pays.
(une partie de ce commentaire est ironique, à toi de découvrir laquelle)
[^] # Re: Petit détail...
Posté par DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Petit détail...
Posté par B16F4RV4RD1N . Évalué à 7.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Petit détail...
Posté par Kerro . Évalué à 6.
[^] # Re: Petit détail...
Posté par houra . Évalué à 2.
Au pire , tu proposes des patchs de traduction des commentaires pour aider au projet, ça sera ptet plus efficace que demander à la personne qui a choisi de rendre visible son code auprès des professionnels qui sont ici et francophones, et prêt, apparemment à soutenir la lecture critique de son code, de faire quelque chose qu'il n'a pas envie.
Et si ça se trouve, ptet que le développeur réussira ainsi à centraliser un système qui finalement s'étendra au monde entier.
( déjà, il peut toucher + de 280 Millions d'individus dans le monde, et s'il traduit en Espagnol, il dépassera largement le quota des gens qui parlent Anglais ).
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Petit détail...
Posté par Kerro . Évalué à 2.
56,41% des mauvais développeurs ne lisent pas correctement l'anglais technique.
Ces données proviennent de la fondation Carambar (http://fr.wikipedia.org/wiki/Carambar#Culture_populaire )
Ce qui n'empêche pas d'avoir beaucoup de développeurs francophones. C'est juste que nous sommes un pouillème du cheptel. Et si le logiciel vient à être utilisé... ben les non francophones le déconseillerons fortement (pas possible de comprendre le source, c'est kif-kif du closed source).
[^] # Re: Petit détail...
Posté par houra . Évalué à 4.
Après je sais pas comment ni pourquoi ceux qui ont écrit ce projet le font , mais je les soutiens à fond dans l'usage du Français. Et je pense qu'à un certain moment, les commentaires laissant penser que l'Anglais serait la langue obligatoire pour toute personne vivant sur Terre n'est rien d'autre au pire qu'une volonté de refuser toute évolution culturelle francophone, hispanique, arabe, russe ou chinoise, au mieux qu'un snobisme. Tous deux sont profondément malsains.
Et tous deux contribuent à se couper d'une base importante de développeurs, qui travaillant avec les outils de Microsoft, ont accès à tout ce qui leur est nécessaire dans leur langue de prédilection. ( MSDN ).
Sur le pouième , comme je l'ai suggéré plus haut, rien n'interdit les traducteurs que le code gêne de proposer des patchs avec des commentaires en Anglais. ( Sinon, les Américains qui ont fait des études devraient pouvoir se débrouiller avec les outils de traduction et leurs amis , si vraiment ce projet a les reins pour devenir international ).
Comment a fait de Brogglie ? Comment ont fait Marie Curie et Bohr ? Est-il plus important de "ne pas se couper de Berkeley " , ou de " ne pas se couper de Julie Martin " qui a envie d'un Facebook à la Française sans la rétention et la revente des données ?
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Petitdétail...
Posté par tesiruna . Évalué à 2.
sens il est normal de rester cohérent et d'avoir la totalité du code source en
anglais (les variables/fonctions évidement, mais aussi les commentaires).
Si le langage utilisé avait été le LSE ou le GOTO++, je n'aurais pas trouvé
choquant que les sources soient intégralement en français.
[^] # Re: Petitdétail...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Petitdétail...
Posté par houra . Évalué à 2.
Par exemple , Le sens de " if " est totalement différent en C et en Anglais.
Son emploi est complètement différent et les règles de grammaire n'ont strictement rien à voir.
Idem pour tous les mots clés.
Quant aux noms de fonctions, ce sont des noms de fonctions, personne n'est capable d'en connaître l'usage et ses limites sans jamais avoir lu le manpage de ces fonctions.
Exemple :
isValid() : C'est une fonction qui détermine si le client est handicapé ou s'il est valide ?
isTrue() : C'est une fonction qui vérifie si le client a dit la vérité ?
Bref, trop de raccourcis , trop d'amalgames font des mauvais programmeurs.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re:Petitdétail...
Posté par tesiruna . Évalué à 3.
avec le site du zéro et qui écrivent leur code en français. Mais peut-être as-tu
la chance de vivre dans un monde parallèle où les meilleurs codeurs sont ceux
que je viens de décrire.
Quoi que finalement je ne t'envie pas.
[^] # Re: Re:Petitdétail...
Posté par houra . Évalué à 2.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Petitdétail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
Le nom des fonctions doit permettre au client de ta fonction (ou de ta classe, objet, etc) de pouvoir l'utiliser rien qu'en lisant son nom et son prototype. Si ce n'est pas le cas, c'est qu'elle est mal-nommée, imbuée d'un piège à con idiotique ou idiosynchratique.
Par contre je ne comprends pas ta remarque sur le if. On en m'a jamais encore relevé à l'emploie de « if » dans une phrase.
if self.isStupid(): self.sparkStupidThingsTo(you)
if I am stupid, then I'm sparking stupid things to you.
[^] # Re: Petitdétail...
Posté par houra . Évalué à 2.
il dit qu'il faut apprendre à lire le Français, déjà.
Le nom des fonctions doit permettre au client de ta fonction (ou de ta classe, objet, etc) de pouvoir l'utiliser rien qu'en lisant son nom et son prototype. Si ce n'est pas le cas, c'est qu'elle est mal-nommée, imbuée d'un piège à con idiotique ou idiosynchratique.
et ?
Le fait de savoir les codes , la méthode pour lire correctement une fonction dont le nom provient de l'Anglais a-t-il réellement une relation avec l'Anglais ?
http://download.oracle.com/javase/1.4.2/docs/api/
-> java.sql
Interface PreparedStatement
public interface PreparedStatement
extends Statement
An object that represents a precompiled SQL statement.
A SQL statement is precompiled and stored in a PreparedStatement object. This object can then be used to efficiently execute this statement multiple times.
Note: The setter methods (setShort, setString, and so on) for setting IN parameter values must specify types that are compatible with the defined SQL type of the input parameter. For instance, if the IN parameter has SQL type INTEGER, then the method setInt should be used.
If arbitrary parameter type conversions are required, the method setObject should be used with a target SQL type.
In the following example of setting a parameter, con represents an active connection:
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
SET SALARY = ? WHERE ID = ?");
pstmt.setBigDecimal(1, 153833.00)
pstmt.setInt(2, 110592)
bon, et maintenant, l'Anglais :
http://www.thefreedictionary.com/prepared
prepared
adjective
1. willing, minded, able, ready, inclined, disposed, in the mood, predisposed, of a mind Are you prepared to take industrial action?
2. ready, set, all set I was prepared for a long wait.
3. fit, primed, in order, arranged, in readiness, all systems go (informal) The country is fully prepared for war.
http://www.thefreedictionary.com/statement
statement
noun
1. announcement, declaration, communication, explanation, communiqué, proclamation, utterance He now disowns that statement, saying he was depressed when he made it.
2. account, report, testimony, evidence statements from witnesses to the event
L'anglais est bien plus complexe que le simple nommage d'une fonction.
Pareil pour " if" . Tu peux toujours chercher des cas dans lesquels le sens de " if " en Anglais ressemble à la simple condition de boucle de beaucoup de langages ( traduisant en fait une série d'instructions à passer au processeur ) , mais une simple visite à la page http://www.thefreedictionary.com/if te montrera que tu as tout à fait tord de chercher le moindre point commun .
Enfin, l'illustration de tes deux dernières lignes montre qu'il y a au niveau de la phraséologie une construction totalement différente entre le langage utilisé et l'Anglais.
Sedullus dux et princeps Lemovicum occiditur
[^] # Décalage
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Je ne vois pas le conflit entre l'usage de prepared dans le concept des requêtes préparées.
Quand au conditionnel en anglais, effectivement, je ne le maîtrise pas. Je parle ce Globish que j'ai appris dans les documentations informatiques.
[^] # Re: Décalage
Posté par houra . Évalué à 2.
Je ne vois pas le conflit entre l'usage de prepared dans le concept des requêtes préparées.
Heureusement que les personnes qui ont inventé cette fonction ne l'ont pas nommée par antinomie .
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Décalage
Posté par Gniarf . Évalué à 4.
foutaises. c'est courant à l'armée ou dans n'importe quelle bureaucratie et autres enfers à procédures
[^] # Re: Petit détail...
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Il faut voir aussi qu'il y a des gens qui ne parlent tout simplement pas (ou mal) anglais.
Et oui c'est un énorme handicape en informatique.
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
[^] # Re: Petit détail...
Posté par lasher . Évalué à 7.
Une connaissance qui bossait avec une boite japonaise me disait qu'au final il préférait quand ils commentaient en jap, parce qu'en anglais leurs commentaires ne voulaient juste rien dire (et oui, le pote en question parlait suffisamment bien japonais pour dire ce genre de choses).
J'ai une règle simple : il faut que le code en lui-même (variables comprises) soit écrit en anglais pour une raison tout bête : les langages info sont écrits en "anglais", et faire un mélange des genres est à mon sens une mauvaise idée. Par contre, les commentaires doivent avant tout être compréhensibles pour les développeurs actifs. Si ceux-ci sont majoritairement francophones, pourquoi ne pas écrire en Français ?
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Le français n'est pas une bonne idée pour commenter du code écrit en anglais, pour plusieurs raisons. La première, c'est que les structures de langage sont en anglais (hors horreurs verbeuses comme le W-Langage). La deuxième, c'est que le français prend plus de place pour exprimer la même chose, en moins précis (c'est statistique). La troisième, c'est qu'il est horrible et pénible de lire : FILE * fic = open("", "rb") ; Ceci en raison de la nécessité de changer d'aire cérébrale. Nous n'utilisons pas la même aire pour parler anglais ou français, et encore moins pour parser du code. Changer de contexte est couteux en ressource, je préfère donc un code qui me permet de n'utiliser que deux contexte pour ma réflexion plutôt que trois pour cette activité déjà suffisamment complexe. Déjà que j'ai l'aire « râleur » qui s'inflamme dès que je lis le code d'un autre, ou un code que j'ai oublié qu'il était de moi.
[^] # Re: Petit détail...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Ne jamais développer avec magic_quotes ou register_globals activé, on est au 21ème siècle quand même.
file_get_contents c'est bien, curl n'est que rarement nécessaire. Par contre comme déjà dis, le _GET['adresse'] en dur c'est mal. Utilise filter_var stp ou parse_url à la limite. Je conseillerais également de rajouter un contexte (cf. la doc de file_get_contents et de stream_context_create) pour ajouter un timeout, genre :
$context = stream_context_create(array('http' => array('timeout' => 5)));
(de mémoire, vérifie dans le manuel)
Car si le site en face est down, ton script risque de timeout avec le site que tu requête, sans compter qu'attendre plus de 5 secondes une requête c'est bien trop, y'a un souci.
Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?! WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en POST. JAMAIS.
Enfin $array[$_GET['id']] c'est mal aussi, vaux mieux vérifier avant que 1. _GET['id'] existe et est un numérique 2. il ait le droit de taper cet ID-ci. ensuite et ça mange pas de pain, caster la variable en int :
$array[(int)$_GET['id']] = 'bla bla';
De manière générale :
- toutes les variables venant de _GET, _POST, _COOKIE, _REQUEST et même _SERVER doivent être vérifiées, puis castées ou escapées.
- bien avoir conscience de la portée des variables, si tu utilise une variable $id à un endroit, se poser la question d'où vient-elle, es-tu sûr que c'est toi qui l'a forgée et pas par exemple un paramètre de la query string ? (particulièrement important pour les applications installées n'importe où, là ou on ne peux pas être sûr que register_globals est désactivé)
Bref il y a du boulot.
Mais l'idée de fond est intéressante, bon courage, ne pas se décourager avec nos commentaires techniques, ils ne sont là que pour t'aider à t'améliorer. La sécurité est importante, et c'est vrai que quand on débute on n'y pense pas vraiment (j'en suis le premier exemple), mais il faut la prendre en compte.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à 0.
« file_get_contents c'est bien, curl n'est que rarement nécessaire »
Je vais remplacer file_get_contents par curl juste pour de la performance :
Lorsque l'on sauvegarde une page, il faut que toutes les requêtes partent en même temps au lieu de partir l'une après l'autre.
« Un autre truc qui me choque : tu stocke le mot de passe dans le COOKIE ?! WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en POST. JAMAIS. »
Bah heu... Tout le monde fait ça, non ...?
Et puis, je vais pas demander au client de retaper le MDP chaque session ?
« Enfin $array[$_GET['id']] c'est mal aussi, vaux mieux vérifier avant que 1. _GET['id'] existe et est un numérique 2. il ait le droit de taper cet ID-ci. ensuite et ça mange pas de pain, caster la variable en int : »
Non, il a le droit de mettre n'importe quoi ici. Normalement les ID que tapage fournis sont genre « bloc_(INT) ». Mais ça peut être n'importe quoi ça marche.
« bien avoir conscience de la portée des variables »
Oui oui, ajax.php c'est juste plein de conditions l'une à la suite des autres. Donc on commence chaque condition sans aucune variable ( sauf ceux qui sont tapé dans config.php mais c'est tout).
[^] # Re: Petitdétail...
Posté par tesiruna . Évalué à 6.
> WTF ! On ne stocke jamais de donnée sensible dans les cookies, en GET ou en
> POST. JAMAIS. »**
>
>
> Bah heu... Tout le monde fait ça, non ...?
>
> Et puis, je vais pas demander au client de retaper le MDP chaque session ?
À mon avis, tu devrais apprendre un peu la programmation web, les choses simples
comme les cookies de session, avant de lancer de gros projets qui ont pour but
d'être sérieux, parce que là votre niveau d'incompétence m'inquiète.
[^] # Re: Petit détail...
Posté par Alex . Évalué à 3.
Bah heu... Tout le monde fait ça, non ...?
Et puis, je vais pas demander au client de retaper le MDP chaque session ?
Je t'invite à regarder les cookies utilisés par linuxfr.
Généralement, après authentification, tu inscris dans le cookie une valeur aléatoire connue du serveur et du navigateur.
Tant que le cookie est valide, l'utilisateur reste authentifié, si le cookie expire, que tu vires cette valeur de ta base de donnée, ou que le cookie expire, l'utilisateur n'est plus authentifié. Tu peux également vérifier le couple id de session/ip, ca n'est pas magique, mais ça rend le vol de cookie un tout petit peu moin efficace.
Je ne maitrise pas php, mais il me semble que c'est ainsi que sont gérés les sessions (variable $SESSION ou un truc comme ça, mais là je dis ptet une connerie).
[^] # Re: Petit détail...
Posté par dededede4 . Évalué à 1.
Tant que le cookie est valide, l'utilisateur reste authentifié. »
Haaa, je ne connaissais pas du tout.
Je note pour la prochaine version. :]
[^] # Re: Petit détail...
Posté par Larry Cow . Évalué à 6.
Désolé si ça te paraît hautain, décourageant et/ou condescendant, mais c'est un peu flippant pour la suite. Ce à quoi tu t'attaques - réseau social décentralisé - n'est pas un problème tout à fait trivial. Ton idée de départ, sur le papier, n'est pas mauvaise (en tous cas j'avais caressé quelque-chose de similaire il y a un temps, et je ne suis pas le seul). Par contre, tu sembles vouloir à tout prix réinventer la roue, plutôt que de t'appuyer sur des protocoles existants (XMPP & co). Cela peut se justifier par ta volonté initiale de faire un truc hébergeable "sur le premier site free.fr qui traine", mais c'est une contrainte forte.
Et malgré cela, tu sembles débarquer complètement dans la monde du développement web - voire du développement tout court - et l'idée qu'un mot de passe puisse circuler en clair dans chaque requête faite au serveur ne t'a pas ému plus que cela.
Pardon d'être aussi direct, mais je penses que tu gagnerais - sans parler du reste du monde - à suivre de près un projet existant (tu as le choix) pour :
* t'habituer à lire du vrai code déjà écrit avec de bonnes bases
* te faire la main sur des petites contributions cosmétiques/mineures
* te faire une réputation dans leur communauté pour proposer ensuite des idées/directions plus audacieuses - ce qui semble être ton point fort.
C'est très courageux de se lancer dans l'implémentation de ses idées, mais ce n'est pas une raison pour faire l'impasse sur les fondamentaux. À plus forte raison quand ton implémentation a vocation à être utilisée par beaucoup de gens : les faiblesses inhérentes à ta réalisation risquent d'être d'autant plus pénalisantes.
[^] # Re: Petit détail...
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
Pour le coup du cookie... Je t'invite à lire une doc sur les sessions PHP... Un petit exemple de login :
session_start();
if (sha1($_POST['password'] . 'secret') == $user['password'])
{
$_SESSION['logged'] = true;
}
if (!empty($_SESSION['logged']))
echo "Je suis connecté";
Note que ici le mot de passe est stocké hashé avec un salt général, ce que tu devrais toujours faire (ne jamais stocker de mot de passe en clair, autre base de la sécurité).
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Petit détail...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
# version 0.15 ou 0.1.5 ?
Posté par François Trahay (site web personnel) . Évalué à 3.
Le développeur principal de tapage s'est donné comme objectif de corriger ces défauts pour la version 0.2
Il n'y a pas comme un problème de numéro de version ?
[^] # Re: version 0.15 ou 0.1.5 ?
Posté par blobmaster . Évalué à 5.
0,2 euros ça fait plus que 0,15
Bizarrement, il utilisent peut-être des réels (en notation anglaise) et non des nombres séparés par des points.
[^] # Re: version 0.15 ou 0.1.5 ?
Posté par Christian Foucher . Évalué à 2.
Tu connais le nommage de version de pugs?
http://fr.wikipedia.org/wiki/Pugs#Num.C3.A9ros_de_version
http://linuxfr.org/~CrEv/20195.html
ou encore le nommage des version de Tex,
http://en.wikipedia.org/wiki/Software_versioning#TeX
# C'est un concurrent de Diaspora ?
Posté par manatlan (site web personnel) . Évalué à 3.
http://joindiaspora.com
Mais bon, facebook est loin d'être mort .... et "google me" arrive a grands pas ...
L'avenir est le social, ça c'est clair.
[^] # Re: C'est un concurrent de Diaspora ?
Posté par dededede4 . Évalué à 2.
Après, la « concurrence » c'est le bien.
[^] # Re: C'est un concurrent de Diaspora ?
Posté par vincent_k (site web personnel) . Évalué à -2.
[^] # Re: C'est un concurrent de Diaspora ?
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est un concurrent de Diaspora ?
Posté par Misc (site web personnel) . Évalué à 8.
[^] # Re: C'est un concurrent de Diaspora ?
Posté par DLFP est mort . Évalué à 6.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: C'est un concurrent de Diaspora ?
Posté par Antoine . Évalué à 10.
# Ta page où est /b/
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Euh… C'est une tentative d'écrire « user-friendly, » ça ?
Car « friand » en anglais, c'est « qui aime énormément, » comme en français d'ailleurs. Là, je lis que le projet n'aime pas les utilisateurs…
>> le CSS fait mal aux yeux
Il me semble que « le CSS, » c'est bizarre. On dit « la CSS » pour parler du visuel. Éventuellement, « le code (de la) CSS, » non ?
>> Le développeur principal de tapage s'est donné
Pour être cohérent avec le reste de la dépêche, il faudrait écrire « Tapage. » Ou mieux, mettre le nom du projet en italique.
[^] # Re: Ta pageoùest /b/
Posté par tesiruna . Évalué à 2.
[^] # Re: Ta pageoùest /b/
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.