L'Ile du Coeur
Mais Murthy, si je fais une modification via JS, la police de caractère ne reste pas sur toutes les pages du site, je suis obligé de stocker dans un $_SESSION 4

Ah mais en fait, tous les hébergeurs, c'est les images des partenaires = ) Faut que je les ré-enregistre sur mon serveur ? C'est vraiment utile pour 10 images de 4ko qui sont absolument pas importantes pour la bonne lecture du site ? :o

Le mot de passe est bien hashé, j'utilise un encrypt, du sel, et je hash (enfin, étant donné que le hash c'est une fonction PHP, je sais pas exactement comment ça fonctionne :o)
Sauf que sur ma page de connexion spéciale, du coup j'envoie ce qui a été inscrit dans la BdD et je fais une vérification simple avec un = et pas une vérification du hash :o (Dans ma page de connexion normale, j'utilise une fonction PHP pour vérifier que le code entré correspond au code hashé). Enfin, encore une fois, il est possible que je me trompe dans les termes. Je me doute bien que c'est pas du tout la bonne méthode de permettre de se connecter via le code hashé directement, mais c'est une solution alternative pour permettre pour l'instant à mes utilisateurs de simplement se connecter s'ils sont oublié leur mot de passe. Je ferai ta méthode par la suite ! (Et encore une fois, ils sont sensé modifier leur mot de passe tout de suite après connexion, du coup c'est comme un identifiant unique, sauf qu'il a pas de durée limité 34")

Ok je crois que je vois la différence entre la XSS et la CSRF 34 (j'ai eu du mal à comprendre l'impact des failles côté client quand j'ai lu, mais c'est bon maintenant 2 )

Pour le dom, je sais pas utiliser ça en JS ni à quoi ça correspond 4 Faudrait que je regarde.

Par contre, le striptag c'est un mix entre addslach et html*** en fait ? Du coup je dois toujours addslash les données à enregistrer mais pas les striptag, on est d'accord cette fois ? :o

Merci pour toutes ces infos 1
Répondre
Pour garder l'information il y a le cookie ;-)
Répondre
Omg je n'avais pas pensé à la simplicité du JS pour ça XD
Enfin, si je veux l'intégrer par la suite dans les profils, autant rester sur le PHP 34
Répondre
Citation : Pour garder l'information il y a le cookie ;-)
Non.
Y'a localStorage à la limite. Ou la session comme veut le faire L'Omniscient car, comme Ter Rowan l'a dit, le stockage client obligera à re-définir ce paramètre si on change de device/navigateur.

Cette préférence n'a en tous cas rien à faire dans les cookies.

Citation : Ah mais en fait, tous les hébergeurs, c'est les images des partenaires = ) Faut que je les ré-enregistre sur mon serveur ? C'est vraiment utile pour 10 images de 4ko qui sont absolument pas importantes pour la bonne lecture du site ? :o
Pour ma part, ces domaines externes n'ont rien à ficher ici donc si j'avais à le faire, j'hébergerais ces images sur le serveur de jeu oui.

Citation :encrypt
On s'en balance, c'est inutile

Citation :du sel, et je hash
Tu passes par password_hash($value, PASSWORD_BCRYPT, array("cost" => 10))? Le reste, t'as des chances que ce soit "poubelle, mal fait".

Citation :Sauf que sur ma page de connexion spéciale, du coup j'envoie ce qui a été inscrit dans la BdD et je fais une vérification simple avec un = et pas une vérification du hash
Donc quelqu'un qui arrive à lire la BDD (qui tombe sur un dump, ou un admin du jeu, etc) peut utiliser ce hash pour aller changer de password et voler le compte d'un autre. D'où une faille.

Citation :Par contre, le striptag c'est un mix entre addslach et html*** en fait ?
Le striptag, c'est un tas de boue (pour être poli) qui joue aux fléchettes pour essayer de supprimer les tags HTML. Ca ne sécurise rien du tout, ça vire des données anarchiquement, et c'est donc à bannir. Je ne vois pas ce que addslash vient faire là dedans.

C'est simple:
=> Quand tu lis une entrée utilisateur (GET, POST, COOKIE, etc), tu valides qu'elle est bien typée (si tu attends un nombre, tu vérifie qu'il soit là et que ce soit bien un nombre, même principe pour un email, même principe pour une string quelconque [pseudo, nom du joueur, RP, bio, etc])
=> Quand tu sauves en BDD, tu ne fais pas de traitement pourris inutile, tu passe juste par une requête préparée et tu stockes ce que l'utilisateur a enregistré
=> Quand tu affiches la donnée dans la page HTML, tu l'échappes pour le HTML via htmlentities; si tu l'affiches dans une balise script, tu la json_encode
Répondre
Ok content de savoir que j'ai pris la bonne initiative avec la $_SESSION 1

J'ai bien ta fonction hash, sauf que j'ai PASSWORD_DEFAULT en paramètre.
J'ai bien compris que ma méthode de l'envoi du code n'était pas du tout fiable, je modifierai je t'ai dis XD

En fait le striptag permet d'échapper les apostrophes il me semble (ou alors j'ai fail des apostrophes, mais mes apostrophes fonctionnent 45).
Du coup j'utilise toujours striptag pour ça. Mais à la place, il faut que j'utilise addslashes du coup ?
Faut que je gère mes apostrophes 34
Répondre
Hum, je ne sais pas si t'as changé un truc, mais avec les mêmes plugins & les mêmes règles (me semble-t-il), je n'ai pas de soucis sur la page d'accueil depuis un autre poste... Je vais donc regarder: j'ai peut-être chié une règle de blocage (je pense que c'est celle dégageant les partenaires et les sponsors qu'il y a partout qui doit interférer avec l'accueil)

Je crois que PASSWORD_DEFAULT n'est pas recommandé car il peut évoluer et changer d'une version de PHP à l'autre: tu risques alors de n'avoir plus personne capable de se connecter.

Non, comme le dit la doc https://secure.php.net/manual/en/functio...p-tags.php strip_tags vire les tags HTML et PHP (je dirai donc qu'un strip_tags dans un attribut HTML ne protègera de rien du tout). addslashes n'a rien à faire là, je redis: htmlentities() (ou html_specialchars, je ne sais jamais trop laquelle conseiller: d'où le fait de se créer une fonction "html" qui appelle htmlentities [par exemple] et d'utiliser cette fonction "html" en guise d'échappement; comme ça, si c'est plutôt html_spacialchars qu'il faut utiliser, il suffira de change le contenu de "html" et non tous les appels à cette fonction)
Ce ne sont pas les apostrophes le vrai problème. Ce seront les guillemets (dans les attributs HTML), les entités HTML (&machin16 et les tags (<x></x>)
Répondre
Hello, du coup je vais travailler sur un élément qui, je pense, va devenir très important pour le site : la possibilité d'acheter avec des points gagnés dans le jeu des éléments pour personnaliser sa page.
J'ai essayé avec le fond, et franchement, je suis trop content (du coup j'ai changé le fond de ma page, je me sens ailleurs :p)
[Image: test.jpg]

Je vais aussi peut-être permettre de personnaliser les piges (qui volent sur l'index), d'en mettre plus ou moins, de les acheter, de changer les créatures qu'ils sont, choisir s'ils vont sur toutes les pages ou pas... Enfin, bref, comme si on construisait sa petite maison à travers son profil en fait. Ca donnera aussi des objectifs au jeu web et au forum RPG : jouer pour pouvoir s'approprier un peu plus le monde. Et ça donnera aussi peut-être plus envie de rester, fréquenter le tchat etc.

Je suis assez content d'avoir trouvé ça 1 Après faut que je réfléchisses aux autres éléments qui pourraient être personnalisés.
Bon sinon j'ai fais 2/3 ajustements donc la changement de typo GET en POST, ce qui permet du coup de recharger même les pages avec des GET.
J'ai ajouté les utilisateurs passés ces dernières 24h sur l'accueil.
Et voilà, 2/3 autres petits trucs du genre.
Répondre
C'est vrai que ce fond est chouette 2

Perso, tout ce qui est personnalisation de ce style à ta place, je ne m'embêterai pas à le ré-inventer (là aussi): Stylish est un plugin de navigateur (Chrome, Firefox, etc) qui permet aux gens de faire leurs propres personnalisations. Si tu te reposes dessus:
• Tu épargne du code qui n'apporte rien au jeu (la personnalisation et son application sont gérés par stylish)
• Tu étends un peu ta visibilité (les skins Stylish de ton jeu apparaissent sur la banque de skins de Stylish, et tu auras quelques joueurs de plus potentiellement)
• Tu te déleste du travail de personnalisation sur les joueurs (qui seront ravis de "participer" ainsi, et de garder la paternité de leurs personnalisations: les skins qu'ils vont créé et partager resteront à leur nom).

Pour ma part, j'avais le même questionnement pour VariiSpace, et je me suis finalement dit que les personnalisations de ce style, je les laisserai à Stylish & Tampermonkey. Rajouter un simple lien dans la zone "personnalisation" permettant d'aller installer le plugin en 2 clics suffira certainement.

A propos de styling et tout, le petit oiseau qui se ballade dans la page (bon, on aime ou pas, perso, je suis neutre: il fout le camp quand on passe la souris dessus, donc cela ne gène pas trop la lecture, mais sur mobile je ne suis pas certain que ce soit possible de "placer le curseur" sur l'oiseau!) peut déformer ladite page: quand il apparait trop près du bord droit, une scrollbar horizontal apparait

Citation :ce qui permet du coup de recharger même les pages avec des GET.
Je n'ai pas compris?! Les pages en GET peuvent être rechargées sans problème (invariance), celles en POST génèreront une confirmation de la part du navigateur.
Répondre
Huuum, je vais regarder Stylish. Mais ce qui m'intéresse le plus dans l'optique de la personnalisation, c'est gagner des éléments par le jeu, devoir les débloquer etc. Que la personnalisation soit un but du jeu. Du coup déléguer ça à une plate-forme extérieure, c'est un peu l'exclure du jeu et la rendre annexe :p
Je donne un exemple tout con, mais si je veux me sentir dans un fond plus "lune", je vais vouloir gagner le fond lune, et du coup je vais me motiver à jouer pour l'avoir.
Et puis j'aimerais que ce soit pas que des fonds, je sais pas exactement encore quoi, mais j'avais aussi l'idée de faire son habitation par exemple, en pouvant personnaliser plein de choses... Enfin je sais pas, tout ça c'est à l'étude, le changement de fond était un premier essai qui a plutôt été bien accueilli 2

Je t'avoue que j'ai pas du tout travaillé la plate-forme pour mobile. Le jeu web est bloqué sur mobile, et écrire du RP sur mobile c'est bof... Le seul élément que je pourrais travailler sur mobile c'est la lecture, mais faudrait que je fasse une vraie interface responsive, je suis pas sûr que ce soit la priorité du tout 34

J'ai plus la tête dans le truc, je sais plus quel était le soucis avec le GET, mais en gros, quand t'es dans un sujet avec ?titre=blabla, je ne pouvais pas récupérer ?titre=blabla sans faire quelques lignes de code supplémentaires. Avec le POST je fais une actualisation de la page sans récupérer d'URL, du coup j'ai pas ce soucis 34
Répondre




Utilisateur(s) parcourant ce sujet : 1 visiteur(s)