[Résolu] Session et ajax

[Damocorp]

Salut,

J'ai fait des tests récemment, et je ne suis pas parvenu à modifier la session utilisateur à l'aide d'une requête ajax.
Ma conception du jeu étant basé en partie sur les session pour éviter pas mal de requêtes çà la bdd, ça viens légèrement perturber mes plans :cogne:

Ce qui me fait penser que je vais devoir choisir entre ajax ou session.

Vous fonctionnez toujours avec des requêtes à la BDD pour la moindre petite chose sur vos jeux ou vous avez beaucoup d'ajax ?

Ou j'ai merdé quelque part, et on peut bien modifier une session utilisateur depuis un script exécuté via une requête ajax ?

[Sephi-Chan]

Je stock le moins de choses possibles en session. Le plus souvent rien du tout. La session implique toujours u système de stockage sous-jacent : un fichier, une ligne dans une base SQL, une clé dans Memcache ou Redis, etc. Autant donc utiliser directement ces outils pour stocker des choses : ça donne un meilleur contrôle.

Je n'essaye pas spécialement d'éviter les appels à la base de données car globalement ça va très vite : le plus long est d'établir une connexion, les requêtes en elle-même sont le plus souvent très rapides (surtout celles de type where id = X).

Je stock seulement un jeton d'authentification de mes utilisateurs dans un cookie chiffré (plutôt que leur ID, ainsi il me suffit de modifier ce jeton dans la table pour déconnecter un joueur).


Sinon j'utilise de plus en plus de single page apps (avec Backbone), donc on fait difficilement plus efficace puisque je ne recharge jamais de page et que les échanges avec le serveur se limitent à des petits bouts de JSON.


À mon avis ton essai est foireux.

[Damocorp]

Y'a une chose que je pige pas vraiment. Comment tu déconnecte ton joueur en changeant son jeton d'authentification si tu ne recharge pas la page ?
Tu as une requête qui tourne à intervalle régulière pour vérifier qu'il est authentifié ?

[php_addict]

perso je stocke en sessions (stockées elle même en base de donnée mysql) très peu de données: l'id du joueur et 2 ou 3 trucs hyper essentiel et extrêmement récurent. Dans mon cas vu que les sessions sont en bdd je devrais de toute façon interroger la bdd pour choper les infos, donc autant mettre le moins de choses possible en session...

[Aleskweb]

Comment tu déconnecte ton joueur en changeant son jeton d'authentification si tu ne recharge pas la page ?

Je suis pas sur d'avoir compris ce que tu demandes, mais méthode un peu barbare, que j'utilise, tu crée une page destroy.php, avec dedans:

Code :

<?php
session_destroy();
?>

Puis tu le charge mettons avec Jquery a l'aide d'un load dans un div loader ou d'un getScript.

[Sephi-Chan]

Y'a une chose que je pige pas vraiment. Comment tu déconnecte ton joueur en changeant son jeton d'authentification si tu ne recharge pas la page ?
Tu as une requête qui tourne à intervalle régulière pour vérifier qu'il est authentifié ?

Chacun de mes utilisateurs dispose d'un attribut persistence_token, que je stock dans un cookie quand le joueur se connecte (ou s'inscrit). Il m'est ainsi possible de rechercher un utilisateur par ce token quand je souhaite savoir qui est l'utilisateur courant (grâce à ma méthode current_user.

Si je veux que le site traite un visiteur comme un invité lors de sa prochaine visite, je n'ai qu'à changer le jeton de ce joueur dans la base de données, ainsi son cookie ne correspondra plus à personne.

[Damocorp]

Ok ça je pige.

Si le joueur se présente, cookie valide en poche, tu l'auto authentifie ? Ou tu lui laisse quand même le choix de mettre un login et pass différent de son cookie actuel ?
Ma question étant bien sûr orienté vers la gestion des multi-comptes

[php_addict]

Ma question étant bien sûr orienté vers la gestion des multi-comptes

ceux qui font du multi et qui sont pas trop débiles savent ce que sont les cookies, ip, proxy, signatures de navigateurs, etc...

[Sephi-Chan]

S'il a un jeton valide, il est authentifié. Ce cookie n'expire pas et est chiffré : toute modification entraîne son invalidation (à moins d'avoir la clé de chiffrement, mais ça, seule mon application la possède).

L'utilisateur peut bien entendu se déconnecter de son compte actuel et se connecter à un autre.

Après, selon l'application, je peux créer des comportements différents : par exemple changer le token dès qu'un joueur se connecte. Ainsi, un seul navigateur peut avoir un jeton valide à la fois (pour ce compte). Ou bien changer le jeton dès qu'un joueur se déconnecte, afin d'invalider le cookie de tous les navigateurs (toujours pour ce compte).

Mais je suis plutôt du genre à ignorer la traque au multi-comptes tant c'est un gaspillage d'énergie.

[Damocorp]

Ok merci pour infos.
J'suis bien d'accord pour les multi-comptes, je les autorise, et je les gère via les paramètres du jeu. C'est plus simple.