Et en plus, en vrai, ca consiste aussi à donner des indications qui permettent de progresser, et si possible dans la bonne direction. Ce qui nécessite de connaître les difficultés habituellement rencontrées. Ainsi que de maîtriser le sujet.
Autant dire que la soi disante correction par les pairs, c'est pas très sérieux.
la personne n'a pas changer le mot de passe en mot de passe vide d'ailleurs je trouve que dans l'exercice cela devrait être noté afin de standardisé les connexions SQL (de même que de demandé l'utilisation de lien relatif et non absolu)
Un jour les Valaisans domineront le monde. Mais pas demain, ya apéro
quenti77 a écrit:
> Je vous laisse me dire quel note vous auriez mis juste pour comparer.
Je ne sais pas quel est le niveau attendu par les critères, mais voici ce que j'aurais personnellement mis.
Présence des fichiers : 1/1, même si j'aurais préféré n'attribuer que la moitié des points. Les fichiers requis semblent bien là (enfin je suppose, je n'ai pas l'énoncé), mais sont aussi présents des fichiers qui n'ont pas à l'être. Que vient faire ici le répertoire .idea ?
Présentation du code : 1/2, un fichier contient à la fois du HTML et du PHP, le rendant plus difficile à lire. Et par la présence d'un appel à exit qui n'a pas lieu d'être. Niveau présentation toujours, les espaces ne sont pas cohérentes. Pourquoi passer par des variables de session pour stocker les messages d'erreur ?
Le reste est plus compliqué, n'ayant pas d'interpréteur PHP sous la main.
Envoi de message : 1/2, la requête a l'air ok, mais pas de gestion d'erreur sur son exécution.
Mémorisation du pseudo : 1/2, il est bien enregistré mais c'est inutilement compliqué (pourquoi enregistrer toutes les variables post ? et pourquoi chercher à le stocker dans deux variables de session différentes ?).
Formatage de la date : 1/1, mais je ne sais pas quel format est attendu. Aussi je trouve bizarre que la fonction format Date insère « Envoyé à » avant la date, ce n'est pas son rôle. Et pourquoi est-elle formatée en deux temps ? (j'enlèverais aussi un demi point si c'est possible).
Vérification XSS : 2/2, ça semble bon.
Soit 7/10 ou 6/10 si les demi-points sont permis. Donc ce que tu as obtenu en moyenne.
Au niveau du CSRF par contre, je pense que le token devrait être invalidé aussi en cas d'erreur.
Et je comprends l'absence de notation pour non connexion à la base, mais que dit l'énoncé ?
Le fichier create.sql est-il d'ailleurs demandé ou un schéma est-il imposé ?
quenti77 a écrit: > Je vous laisse me dire quel note vous auriez mis juste pour comparer.
Je ne sais pas quel est le niveau attendu par les critères, mais voici ce que j'aurais personnellement mis.
Présence des fichiers : 1/1, même si j'aurais préféré n'attribuer que la moitié des points. Les fichiers requis semblent bien là (enfin je suppose, je n'ai pas l'énoncé), mais sont aussi présents des fichiers qui n'ont pas à l'être. Que vient faire ici le répertoire .idea ?
Présentation du code : 1/2, un fichier contient à la fois du HTML et du PHP, le rendant plus difficile à lire. Et par la présence d'un appel à exit qui n'a pas lieu d'être. Niveau présentation toujours, les espaces ne sont pas cohérentes. Pourquoi passer par des variables de session pour stocker les messages d'erreur ?
Le reste est plus compliqué, n'ayant pas d'interpréteur PHP sous la main.
Envoi de message : 1/2, la requête a l'air ok, mais pas de gestion d'erreur sur son exécution.
Mémorisation du pseudo : 1/2, il est bien enregistré mais c'est inutilement compliqué (pourquoi enregistrer toutes les variables post ? et pourquoi chercher à le stocker dans deux variables de session différentes ?).
Formatage de la date : 1/1, mais je ne sais pas quel format est attendu. Aussi je trouve bizarre que la fonction format Date insère « Envoyé à » avant la date, ce n'est pas son rôle. Et pourquoi est-elle formatée en deux temps ? (j'enlèverais aussi un demi point si c'est possible).
Vérification XSS : 2/2, ça semble bon.
Soit 7/10 ou 6/10 si les demi-points sont permis. Donc ce que tu as obtenu en moyenne.
Au niveau du CSRF par contre, je pense que le token devrait être invalidé aussi en cas d'erreur. Et je comprends l'absence de notation pour non connexion à la base, mais que dit l'énoncé ? Le fichier create.sql est-il d'ailleurs demandé ou un schéma est-il imposé ?
- Edité par entwanne il y a 36 minutes
Présense des fichiers requis : Le .idea tu le voit car l'ide phpstorm le mets et sur linux il est caché donc moi perso je ne le vois pas et au pire des fichiers en plus ne font pas perdre de points.
Présentation du code : j'ai fait en sorte d'être au niveau des chapitres du cours (pas au niveau du cours mais de ce qui est présenté) Si j'avais du le faire en vrai j'aurai fait ça en node ou autre. Ou si c'était en php ça serait avec du mvc et de la poo. Mais déjà que les correcteures on mis que c'était du code compliquer alors imagine avec de la poo D'ailleurs à cela j'y ajoute que comme je travail en "MVC" avec laravel je peux formatter le html, css et js avec 2 espaces et le php avec 4. Ce qui fait des choses bizarre forcément commme j'ai tout mis au même endroit.
Envoi de message : une requête juste syntaxiquement ne plante jamais et si les format de données sont respecté elle à aucune raison de planter. Si ça devait arrivé c'est que un cas plus haut n'a pas été gérer mais la requête en elle même ne doit pas planter. Si la connexion au serveur SQL échoue à ce moment là ba de toute façons on peut plus rien faire pour la suite donc l'utilisateur aura une page de template lié à l'erreur SQL
Mémorisation du pseudo : En fait il y a un truc en plus que je gère qui sont les erreurs et en effet c'était pas demandé donc ça ajoute une complexité supplémentaire. Comme je gère les erreurs je gère la sauvegarde des données pour pouvoir les remettres dans le formulaire surtout si le mec avais mis un long message et à oublier son pseudo.
Formattage de la date : Je suis d'accord pour le envoyé à, j'ai hésité sur le coup et comme j'ai fais ça rapidement je l'ai laisser. Par contre le formattage est en 2 temps car il fallait une date en français donc le mois en français. C'est pas la meilleurs des solutions mais c'est la plus simple (j'ai plus l'habitude de carbon sur laravel).
Le token csrf est forcément invalidé par la redirection de page mais on pourrait pu remettre une nouvelle valeur niveau session pour être sur. Après c'est en plus dans l'exo mais pour moi ça reste une faille.
Le fichier create.sql est demandé car il n'y a pas de schéma type.
Par contre la présence du exit tu parle du/des quel(s) ?
Et la session pour les erreurs / info / success / warning c'est ce que l'on appel un message flash. C'est comme ça que l'on fait et c'est beaucoup plus simple de le gérer comme ça
quenti77 a écrit:
> Présense des fichiers requis : Le .idea tu le voit car l'ide phpstorm le mets et sur linux il est caché donc moi perso je ne le vois pas et au pire des fichiers en plus ne font pas perdre de points.
Ce n'est pas une raison, ça n'a rien à faire là. Je le vois lorsque j'explore l'archive avec emacs par exemple. C'est comme si dans ton rendu il y avait un dossier avec tes photos de vacances. Ça alourdit et pollue inutilement l'archive.
quenti77 a écrit:
> Envoi de message : une requête juste syntaxiquement ne plante jamais et si les format de données sont respecté elle à aucune raison de planter. Si ça devait arrivé c'est que un cas plus haut n'a pas été gérer mais la requête en elle même ne doit pas planter. Si la connexion au serveur SQL échoue à ce moment là ba de toute façons on peut plus rien faire pour la suite donc l'utilisateur aura une page de template lié à l'erreur SQL
Si une requête peut planter. Si la table n'existe pas, n'a pas le bon format, si une contrainte n'est pas respectée ou d'autres encore. Ici un cas improbable mais possible serait de tomber sur un uuid existant déjà en base.
Et cest justement dans le cas de l'erreur SQL dont tu parles que le jeton csrf n'est pas invalidé. C'est le problème à dupliquer la gestion d'erreurs plutôt qu'à utiliser un mécanisme d'exceptions.
quenti77 a écrit:
> Mémorisation du pseudo : En fait il y a un truc en plus que je gère qui sont les erreurs et en effet c'était pas demandé donc ça ajoute une complexité supplémentaire. Comme je gère les erreurs je gère la sauvegarde des données pour pouvoir les remettres dans le formulaire surtout si le mec avais mis un long message et à oublier son pseudo.
Il n'est pas pour autant utile de stocker tout le tableau $_POST (pour ensuite le supprimer en cas de réussite).
quenti77 a écrit:
> Formattage de la date : Je suis d'accord pour le envoyé à, j'ai hésité sur le coup et comme j'ai fais ça rapidement je l'ai laisser. Par contre le formattage est en 2 temps car il fallait une date en français donc le mois en français. C'est pas la meilleurs des solutions mais c'est la plus simple (j'ai plus l'habitude de carbon sur laravel).
J'aurais pensé que la méthode format utilisait les locales du système pour renvoyer les bons noms, mais la doc dit que non…
quenti77 a écrit:
> Par contre la présence du exit tu parle du/des quel(s) ?
Le dernier.
quenti77 a écrit:
> Et la session pour les erreurs / info / success / warning c'est ce que l'on appel un message flash. C'est comme ça que l'on fait et c'est beaucoup plus simple de le gérer comme ça
C'est une pratique courante en PHP ? Ça n'en reste pas moins assez sale.
Je pense que je vais te faire la version comme je l'aurai fait ça sera plus simple que de débattre d'un code fait en 30 minutes pour un exercice très minimaliste qui de toute façon n'a aucune valeur pour moi vu que c'est même plus comme ça que je code (le procédurale je parle).
entwanne a écrit:
Ce n'est pas une raison, ça n'a rien à faire là. Je le vois lorsque j'explore l'archive avec emacs par exemple. C'est comme si dans ton rendu il y avait un dossier avec tes photos de vacances. Ça alourdit et pollue inutilement l'archive.
Bon déjà tu compare des fichiers inutile tout court qui font 4 Mo chacun à un dossier de 4 Ko qui me sert pour moi et que j'ai oublier sans faire exprès. Après si tu as une connexion 2 Ko/s c'est pas de ma faute. Et si le correcteur n'a pas de jujotte de ce dire, ce dossier ne sert à rien je l'enlève ou je l'ignore simplement alors qu'il arrête d'apprendre à dev car il sera jamais bon.
C'est vraiment chipotter sur un détails et pour info contrairement à ceux que j'ai corriger au moins j'ai pas mis tout bootstrap dans l'archive pour y inclure le design alors qu'on a les CDN. Pourtant j'ai rien dis sur ça et je les nique pas pour ça. Comme l'a dis un mec sur ce topic, on est là pour juger l'acquis.
entwanne a écrit:
Si une requête peut planter. Si la table n'existe pas, n'a pas le bon format, si une contrainte n'est pas respectée ou d'autres encore. Ici un cas improbable mais possible serait de tomber sur un uuid existant déjà en base.
Et cest justement dans le cas de l'erreur SQL dont tu parles que le jeton csrf n'est pas invalidé. C'est le problème à dupliquer la gestion d'erreurs plutôt qu'à utiliser un mécanisme d'exceptions.
Si la table n'existe pas c'est que tu ne sais pas coder et réfléchir donc désolé pour toi. Si une contrainte n'est pas respecté c'est que tu t'es planté aussi et les tests unitaires, fonctionnels et d'intégration sont la pour ça.
Le jour ou tu as un conflit d'uuid v4 tu m'appel et on discute de tes problème de charge car bon avec 50% de chance d'avoir un conflit d'uuid avec une génération de 1 milliard de ligne par seconde pendant 100 ans je pense que de tomber sur le même directement c'est vraiment ne pas avoir de chance.
Après comme j'ai dis en prod le client vera une page d'erreur et toi tu aura eu le log de l'erreur si jamais ça doit ce produire.
entwanne a écrit:
Il n'est pas pour autant utile de stocker tout le tableau $_POST (pour ensuite le supprimer en cas de réussite).
Pas grand chose à dire car c'est dur de faire mieux c'est faire tout un système de validation avec retour d'erreur.
entwanne a écrit:
quenti77 a écrit:
Par contre la présence du exit tu parle du/des quel(s) ?
Le dernier.
Oui en effet il sert à rien et on sens que j'ai copier coller pour aller vite (une fonction aurait été mieux). Mais vaut mieux avoir un exit() en trop après un header location que d'en oublier un. Je pense que tu chipotte sur des détails alors que le but de l'activité est de voir si la personne à compris ou pas.
entwanne a écrit:
C'est une pratique courante en PHP ? Ça n'en reste pas moins assez sale.
C'est une pratique courante pour beaucoup de langage / framework et j'avoue que je me demande comment tu ferais un message transmis à la page suivante qui se supprime. Car bon c'est bien de dire que c'est sale mais ça enlève ta crédibilité si tu ne dis pas comment mieux faire. Rien que pour celles et ceux qui lirais le topic et pourrais avoir de bon conseil.
De mon côté je vais arrêter de répondre ici car le débat de ce topic s'éloigne peut-être un peu (dites moi si j'ai tord).
@quenti77 : on se calme, on respire, tout va bien. Surtout que @entwanne est un membre expérimenté en programmation, je le sais moi-même. Si l'avis que tu as reçu ne correspond pas à ce que tu voulais entendre, évite d'agresser ceux qui ont pris le temps de te répondre.
Premièrement c'est sale l'inclusion de ce qui n'est pas demandé. Ton dossier fait peut-être que quelques kilo-octets, mais il prouve que tu ne sais pas rendre une archive propre. Alors on peut conjecturer que ton code sera pareil. Ça fait pas pro.
Ensuite si une requête SQL peut planter même si elle est syntaxiquement correct. En informatique, il existe une loi qui dit que tout ce qui peut potentiellement mal tourner tournera mal. Et c'est typiquement dans les cas où on se dit "ça n'arrivera jamais" qu'on s'en mord les doigts quand ça arrive.
Tu dis qu'on chipotte sur des détails, mais c'est aux détails qu'on voit si quelqu'un est un bon dev. Sinon, coder n'importe comment puisque on se fout des détails, on appelle ça pisser du code.
PS : PHP c'est nul, faut coder avec un vrai langage.
le débat de ce topic s'éloigne peut-être un peu (dites moi si j'ai tord).
Non, tu n'as pas tort ... mais c'est toi qui l'as fait dévier en présentant ton travail et en demandant des avis dessus ... le hors sujet était initié ...
Des avis (notes) t'ont été donné avec pertinence il me semble, et pour revenir sur le sujet, si la notation ne te convient pas, relis un peu tous les messages débutant ce sujet ... on y vois tout le problème de la notation, et des préférences de développement de chacun ( subjectivité ) ... et encore, là tu avais voix au chapitre, alors que dans les notations des activités sur OC ... nada ...
Pour ne pas me faire accuser de censeur frénétique ( entwanne ) je vais laisser le sujet en l'état, et simplement vous inviter à reprendre la discussion autour des notations sur les activités OC, en espérant vous proposer une bonne relance
Tout a été dit, les avis sont subjectifs donc le diplôme n'a aucune valeur. Un débutant qui peut faire du bon code sera autant en échec qu'un autre pas très bon.
Les critiques dans l'activité devraient être écrites sur chaque point de la note avec un avis global. Et on devrait pouvoir signaler les avis qui ne semblent pas juste comme par exemple le mec qui n'arrive pas à se connecter à la bdd.
C'est surtout ça que je voulais souligner. Merci en tout cas des critiques qui ont été données. Elles sont toujours plus utiles que les avis dans l'exemple. (aparté, le test que j'ai fait n'est pas pour un futur diplôme, je suis déjà en CDI et on met pas en prod avec un ftp ou un zip )
PS : PHP c'est nul, faut coder avec un vrai langage.
Oui et le JS est mal foutu, Python est lent, etc et etc..
Voilà le type de commentaire qui décrédibilise ton intervention, il me semble qu'un bon développeur doit s'adapter à chaque langage sans arrière pensée. Dons supprimons PHP et laissons de côté les amateurs et ceux qui n'ont pas eu la chance d'aborder l'informatique dans leur parcours scolaire.
désolée de ce petit aparté, récurent sur OC contrairement à d'autres sites/forums.
Et sinon, la correction d'exercices par des débutants qui n'ont aucun recul dessus est effectivement nulle. La note donnée (qu'elle soit bonne ou mauvaise) n'a donc aucune valeur dans la plupart des cas.
Le meilleur moyen pour obtenir des avis sur un exercice quelconque reste d'en poster le code sur le forum et de demander aux membres de commenter. Là il se pourrait que des gens plus expérimentés passent.
Quel égoïsme et mépris envers les autres, en même temps (comme le dit notre cher Président) quand je consulte le forum Python on en voit certains qui prennent les débutants de haut, étalent leurs connaissances sous forme de clan, bref c'est assez peu accueillant...
- Edité par pipelette13 8 septembre 2018 à 13:50:16
Euh, où vois-tu de l'égoïsme et du mépris ?
Un débutant n'a par définition pas le recul nécessaire pour juger le travail d'un autre.
Ce n'est pas méprisant, ce recul viendra simplement avec le temps et l'expérience.
Pour les langages, je fréquente juste le forum C et je trouve que c'est très bien. En particulier il y a une poignée de personnes expérimentées qui interviennent de façon très pédagogique (je pense notamment à Michel Billaud mais il n'est pas le seul). Peut-être que l'ambiance n'est pas la même en fonction des langages ?
Il y a autant d’ambiances que de sous-forums. Sur Vos Études les membres régulier se tapent tellement dessus qu’on se fait modérer sur nos propres sujets entre nous. Et je parle même pas de ban.
Je viens vous voir de la part de l'équipe OpenClassrooms, je viens de prendre connaissance de ce thread grâce à nos (formidables) modérateurs.
Je vois que ça chauffe et c'est bien d'instaurer et de faire vivre le débat.
Nous savons que ce système, en place depuis quelques temps, n'est pas idéal, car tous les utilisateurs ne sont pas attentifs et bienveillants les uns envers les autres.
C'est la raison pour laquelle nous avons deux solutions, une à court et à moyen terme.
1/ Maintenant et jusqu'à ce que la nouvelle feature soit produite, si vous êtes victime d'un abus (une sale note injustifiée), hello@openclassrooms.com. On vous fera repasser la note avec un correcteur raisonnable.
2/ On développe depuis quelques mois un système qui permettra de supprimer définitivement ce genre de problèmes. On l'a pensé au sein de l'équipe, testé, et il est en prod. Sa mise en place est pour bientôt et cela devrait régler ces soucis.
Puisque c'est presque réglé et pour qu'on puisse revenir à des considérations plus sereines, je me permets donc de fermer ce topic.
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
Avatar by MaxRoyo. Venez parler du sdz
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script