Voici ce qu'on pouvait lire sur le forum (ici hein !!) à 14:50 !!

ben, en fait c pas si mineur que ça : ça te fout aussi en l'air les ptites loupiottes qui t'indiquent les nouveaux messages.

après faut expliquer aux utlisateurs pkoi les indicateurs de nvx messages marchent pas.

ET parfois ça crée aussi des pbs de connexion, genre impossibilité de se déconnecter.

Je pensais que ct mon serveur qui bugguait, mais faut croire que non.

Evidemment la solution, c de dire aux gens, vous mettez tjrs les www, (ou l'inverse), mais bon ...

hmmm j'entens par mineur que ça ne mets pas en péril la sécurité

Wala , c'est un problème du au domaine des cookies je pense j'attend splus d'explication d ela part de notre chacal adoré

[quote1]Je propose d'implanter un test sur la validité de l'ouverture d'une nouvelle session. Je m'explique si un user est déja mis en session pas la peine d'en créer une deuxième avec le même user_id[/quote1]

En fait, si on effectue un test, ça sous entend d'éxécuter une requête, et cette option est à bannir... Bon après, il y a une solution qui consisterait à configurer le champ 'username' comme champ de données unique, ce qui éviterait les répétitions. Mais ça empecherait par la même occasion les sessions visiteurs (car leur pseudo est vide et donc, il n'y aurait qu'un maximum d'une seule session visiteur stockée dans la db pour tous les visiteurs). Tu vas me dire: on peut toujours esquiver ce problème, mais ça fait quand même bcp de prise de tête pour un bug mineur qui n'arrivent que si le membre le fait exprés

Sinon en ce qui concerne les blems de sessions visiteurs, l'origine la plus fréquente, c'est celle des cookies, et les fonctions de CF fonctionnent parfaitement, on y peut rien si les utilisateurs n'ont pas leur configuration cookie réglée sur celle nécessaire pour le forum....

De mon côté, pour régler ces 2 problèmes, je serais plutot d'avis de rajouter un champ IP dans la table de sessions, et de configurer ce champ comme champ de données unique, ce qui permettra d'éviter les répétitions d'IP dans la table de sessions...

Mnt, reste plus qu'à voir l'avis du Coyote là dessus

*** Message édité par TiGeR le 14/10/2003 20:24 ***

pr les IPs tu ne peux pas le faire... Si des personnes accèdent au forum via un proxy, toutes ces personnes seront vu comme une seule IP... et risque de problèmes...

et deuxio ton système avec l'IP entraîne aussi une requête sur la bdd donc...

et tertio pr les invités je sais plus mais c particuliers... on peut tjrs définir un seul useridpr els invités genre 0 et ne pas faire ce test ds ce cas précis... et pr l'userid celui là on peut le récupérer via le cookie => pas de requête

[quote3]pr les IPs tu ne peux pas le faire... Si des personnes accèdent au forum via un proxy, toutes ces personnes seront vu comme une seule IP... et risque de problèmes...[/quote3]

Bien vu pour les proxys

[quote1]et deuxio ton système avec l'IP entraîne aussi une requête sur la bdd donc...[/quote1]

Ce système serait basé sur la requete par défaut, donc pas de requetes supplémentaires, juste un champ en plus dans une requete déjà présente.

[quote2]et tertio pr les invités je sais plus mais c particuliers... on peut tjrs définir un seul useridpr els invités genre 0 et ne pas faire ce test ds ce cas précis... et pr l'userid celui là on peut le récupérer via le cookie => pas de requête [/quote2]

Pour l'userid des membres, c'est sûr on peut le récupérer dans le cookie, mais si tu veux tester s'il est déjà présent dans la db, il te faut lancer une requete SQL de sélection. Or, parmi les requêtes déjà présentes, celle de sélection des membres connectés se situe après celle d'insertion. Du coup, ça nous oblige à rajouter une requête juste avant celle d'insertion...

*** Message édité par TiGeR le 14/10/2003 20:37 ***

oui mais je vois difficilement une autre solution... et puis si c'est qu'une seule requête de plus... avec une requête qui compte bah tu perds pas grands chose hein !!

et même qu'il y'a peut être un truc d sla doc mysql pr faire ça en même temps... mais je suis pas un sper pro en sql... donc.. Coyoooooooooooooooooote ????

Bah en fait, on a le même problème avec le champ userid que pour le champ username: la même valeur pour tous les invités.... donc pas de possibilités de le définir comme champ unique

Et pour le coyote, honnetement, je ne pense pas qu'il rajoute une requête en plus pour ça, l'objectif étant d'optimiser CF et d'avoir le moins de requêtes possibles...

Enfin, ptet qu'il a une solution, on verra bien ce qu'il en dit

*** Message édité par TiGeR le 14/10/2003 20:47 ***

C'est bon, je crois avoir trouvé une solution à ton problème directement sur SQL!

En fait, on change la valeur par défaut de userid (ou username) et on la met de type NULL. On configure le champ userid (ou username) comme champ de données uniques. Et lorsqu'un invité utilise la fonction de session, on envoit NULL comme userid (ou username).

Et d'après ce que je viens de tester, les duplications de valeur NULL sont autorisées pour les champ de données uniques, donc plus de problèmes de membres doubles, et pas de soucis non plus pour les invités

hmmm ou alors avec un système de requêtes imbriquées et les opérateurs logiques on devrait réussir notre coup avec 1 seule requête :)

C'est bon, en intervenant sur la structure de la table, même pas besoin de requêtes supplémentaires! Mnt faut avoir l'avis du Coyote là dessus

t'as testé avec un mysql 4 ?? parce que c un poil différent de mysql 3...

Oué je suis sur MySQL 4.0.15 en local

ben suite a ça, j'ai essayé et me suis mis en deux fois aussi ( Ronditudes et Bisounours )

ben quand me suis enlevé (Bisounours) je me suis retrouvé avec 2 Ronditudes. Quand j'ai fermé une des fenetres, il y avait toujours Ronditudes mais je n'était plus identifié.

Il a fallu que je vide mon cache IE5 pour en sortir

Et voilà ce qui arrive quand on fait mumuse à se dupliquer sur CoolForum, il se venge!!

De toute façon, les sessions sont purgées de la table de sessions au bout de 5 mn

Le problème du dédoublement de login est un faux problème. En effet, si tu passes toujours par la même url, tu n'as pas ce dédoublement. Et en fait il ne s'agit même pas d'un bug du système de session mais de la façon dont sont structurés les cookies. Je m'explique:

Le système de session est basé à l'heure actuel uniquement sur les cookies et un numéro de session. Quand tu arrives sur le forum, il regarde si tu as un numéro de session. Si c'est pas le cas il t'en génère un, te l'envoie dans le cookie, et ajoute une ligne dans la session. Si tu en as déjà un il ne fait que mettre à jour la ligne dans la table de session.

Oui mais voilà, pour le système de cookie actuel, http://www.coolforum.net n'est pas le même domaine que http://coolforum.net, donc ton PC va enregistrer 2 cookies différents pour chacun de ces domaines, chacun n'étant ouvrable que sur le domaine qui le concerne.

Voilà la raison pour laquelle par exemple le système de messages lus paraît bugguer, en fait c'est pas du tout le cas, c'est juste qu'on travaille sur un autre cookie. Voilà également pourquoi il apparait 2 fois Jean-Glode vu que les cookies sont différents, tu as un numéros de session différent dans chaque cookie.

A l'arrivée c'est pas vraiment un bug en fait, et c'est pas gênant si tu utilises toujours la même url pour venir sur ton forum. A l'heure actuelle, mon soucis sur les sessions concernent plutôt les visiteurs qui refusent les cookies et qui génèrent un nombre incalculable de visiteurs, l'idée étant de trouver une parade. C'est à l'étude mais c'est pas gagné

Ouvrir une session sur le serveur semble une bonne solution... non ?

le problème est exactement le même.
Déjà tous les serveurs n'acceptent pas les sessions sur le serveur, et chaque session est identifiée par un numéro qu'il faut bien véhiculer de page en page, donc le problème reste entier