+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : l'architecture du site (/showthread.php?tid=5436)
Pages :
1
2
RE: l'architecture du site - Jeckel - 18-05-2011
niahoo a écrit :(18-05-2011, 04:11 PM)Jeckel a écrit : Attention, domaines différent signifie sessions différentes... donc tu auras du mal à récupérer la session de la connexion sur le domaine principale sur les autre domaines. (c'est faisable mais super casses-couilles)
Comment tu ferais ? edit: enfin, je veux dire, t'as une astuce particulière ou bien je tape « cross domain cookie » dans google ?
Je n'ai jamais fait, donc pas d'astuce éprouvée.
Normalement, un cookie est lié à un domaine et ne peut donc être consulté depuis un autre domaine (hors bidouille genre ActiveX ou exploitation d'une faille de sécurité du navigateur) et heureusement, sinon, on pourrait faire du vol de session à tout va.
Donc, le seul truc c'est de passer une clé dans l'URL (genre ID de session) et d'avoir accès sur les deux domaines à un système commun permettant de recharger la session et de créer un nouveau cookie sur le second domaine.
Je déconseillerai l'ID de session (pour éviter qu'il se balade trop facilement) au profit d'un token à usage unique :
- Sur le site A, l'utilisateur s'identifie, login et mot de passe, on créé une session, un laisse un cookie avec l'Id de session, normal quoi.
- Du site A, on souhaite aller au site B.
- Sur le site A, je créé un lien vers une page spécifique (dite de redirection) sur le site A.
Cette page créé dans une base ou dans un système de fichier une correspondance entre l'ID de session et un clé unique.
Puis envoie une réponse de redirection vers la page du site B avec la clé unique dans l'URL
- le navigateur appelle donc la page du site B avec la clé unique
- La page du site B reconnait la clé, va chercher dans la base ou le système de fichier la correspondance avec l'ID de session, Supprime cette correspondance, et rouvre la session et stocke le cookie.
- Ceci suppose que les sessions sont stockées au même endroit pour les deux domaines. (même système de fichier ou même base de donnée)
Voilà, dans la théorie, c'est ce que je ferai... mais jamais testé, et il y a sans doute d'autres méthodes
RE: l'architecture du site - Taaazzz - 18-05-2011
je précise que moi sur mes sites et sur mon futur jeu je n'utilise pas les cookies cotés client genre set cookies(), je n'utilise que les variables $_SESSION qui sont plus sécuriser que les cookies vus qu'eux restent coter serveur.
et je suppose que c'est avec ce système et les frames qu'on peut faire voyager les sessions d'un dns à un autre non?
Fin bon comme c'est mon premier jeu, je pense que je vais faire de la méthode que je connais le mieux, ça sera peut être un jeu à monde unique dans un premier temps et plus tard je verrai comment en mettre un deuxième si le jeu devient populaire ou que je voudrais en faire un avec des options différentes (genre vitesse de jeu etc), même si l’idéale est d'y penser dés le début quand même.
RE: l'architecture du site - Jeckel - 18-05-2011
L'utilisation de la session passe en générale toujours par un cookie.
En PHP l'ouverture d'une session génère la création d'un identifiant unique du visiteur, mais pour suivre sur les pages suivantes de quel utilisateur il s'agit il faut que le navigateur continue d'envoyer à chaque page l'identifiant qui a été généré à l'ouverture de session. Ce passage peut se faire soit par URL (?session_id=123456789) soit par cookie.
La configuration de PHP par défaut créé systématiquement le cookie, et le passage par URL est dangereux.
En effet, si quelqu'un attrape l'URL de l'utilisateur, il peut très facilement lui voler sa session en utilisant son identifiant.
(bon, un vol de session peut se faire même avec le cookie, mais c'est un peu moins facile on va dire).
RE: l'architecture du site - Taaazzz - 18-05-2011
je n'utilise jamais le session_id créé au début de chaque session mais un unique_ID créé lors de l'inscription qui lui n'est jamais stocker chez les utilisateurs mais reste coté serveur, et aucune info ne passe par les url, fin parfois mais pour rien de sensible.
RE: l'architecture du site - php_addict - 18-05-2011
(18-05-2011, 01:14 PM)Jeckel a écrit : Personnellement, je n'utilises pas de frames, je n'en vois pas l'intérêt.
si...mettre une pub qui ne se rafraichie pas à chaque changement de page...
RE: l'architecture du site - niahoo - 18-05-2011
(18-05-2011, 05:51 PM)Taaazzz a écrit : je n'utilise jamais le session_id créé au début de chaque session mais un unique_ID créé lors de l'inscription qui lui n'est jamais stocker chez les utilisateurs mais reste coté serveur, et aucune info ne passe par les url, fin parfois mais pour rien de sensible.
C'est transparent, mais par défaut, quand tu fais session_start() php gère un cookie appelé par défault PHPSESSID.
mais effectivement, ce cookie ne contient qu'une clé, et les variables stockées en session restent côté serveur.
jeckel, en désactivant ses cookies, l'ID de session se met dans l'url, oui, mais par défaut je crois que php compare à l'IP ou un truc du genre. pour avoir essayé ce n'est pas aussi facile à voler la session.
La méthode que tu proposes pour les cross domain cookies est plus ou moins ce que j'ai pu lire sur le net.
Pour avoir l'affichage ou non d'un formulaire de connexion sur un site et le jeu sur l'autre, ça peut être pas mal. mais après je sais pas si ça vaut vraiment la peine de s'ennuyer avec ça au final.
Donc pour ton jeu Taaaz, autant oublier avant que tu en aies ressenti le besoin, ce qui est loin d'arriver à mon humble avis.
Citation :Maintenant pour la structure du dev en lui même, j'ai surtout deux question, est-ce vraiment utile de faire des templates?
disons cue ça t'incitera fortement à séparer le code logique/métier et l'affichage, ce qui est généralement une bonne chose.
et est-ce vraiment utiles de créé un fichier cache du site?
et bin si une page fait une requête lourde pour afficher des infos, et que 1000 utilisateurs la rechargent toutes les 30 secondes et qu'elle affiche toujours la même chose, c'est utile car ça évite d'utiliser la base de données inutilement par exemple.
RE: l'architecture du site - Jeckel - 18-05-2011
(18-05-2011, 06:38 PM)php_addict a écrit :(18-05-2011, 01:14 PM)Jeckel a écrit : Personnellement, je n'utilises pas de frames, je n'en vois pas l'intérêt.
si...mettre une pub qui ne se rafraichie pas à chaque changement de page...
Ah, ben maintenant j'en vois l'intérêt ! merci
RE: l'architecture du site - Taaazzz - 18-05-2011
@ niahoo
oui je sais que par défaut il y a un cookie de créé au lancement de la session avec leur phpid, mais lui je ne l'utilise jamais dans quoi que ce soit, il est là, mais moi je m'en fou.
d'ailleurs, ceci n'a jamais été un de mes soucis, je gère bien les variables $_SESSION depuis longtemps, d'ailleurs je les gère mieux que les cookies avec le truc set cookies()
d'ailleurs vous avez repondu à mes interrogation. Je vais surement devoir à un moment voir comment mettre certaine choses en caches, mais je n'en suis pas encore là.
Pour le template, j'en ai créé qu'un et il était très basique pour le site d'un peintre qui voulait changer l'apparence complet en fonction des saisons... créé ça à l’échelle d'un jeu complet sera une belle expérience, je le sens bien lol
Petite dernière question, je suis tout seul sur mon projet, vous pensez que c'est faisable? ou je devrais me chercher une petite équipe? (de toute façon un jour ou l'autre il me faudra un graphiste pour me faire des images :p )
RE: l'architecture du site - niahoo - 18-05-2011
ben moi je bosse seul. et mon jeu sera moche, et il sortira dans 10 ans.